Description of problem:

I stumbled upon this when working on snapd SELinux policy. When a snap with a socket activated service is installed, we generate a proper socket unit file for systemd, call daemon-reload and start the unit. Socket activated snaps are only allowed to have the socket files under $SNAP_{DATA,COMMON}, i.e. /var/snap/<snap>/.., labeled as snappy_var_t. I have noticed that even though, the snappy policy came with corresponding rules to allow access for init_t, systemd would still fail with denials like this:

----                                                                                                                                                                                                                                                                                                                                                       
time->Mon Dec 17 14:55:47 2018                                                                                                                                                                                                                                                                                                                             
type=AVC msg=audit(1545058547.616:321): avc:  denied  { create } for  pid=1 comm="systemd" name="other" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir permissive=0                                                                                                                                                   
----                                                                                                                                                                                            

Note, that incorrect target context is used, even though, /var/snap/test-snap/dir is labeled as snappy_var_t.

Rebooting or running systemctl daemon-reexec makes the problem go away.

There is an upstream bug report too: https://github.com/systemd/systemd/issues/9997 The ticket also comes with a simple example to demonstrate the problem.

Version-Release number of selected component (if applicable):
systemd-239-6.git9f3aed1.fc29.x86_64

How reproducible:
always

Additional info:
There is a workaround to the problem, but calling daemon-reexec in %post does not sound too appealing. Any suggestions on what could be done by the package maintainer instead?