Bug 1660141
| Summary: | SELinux policy change not not visible to systemd until daemon-reexec or reboot | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Maciek Borzecki <maciek.borzecki> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 30 | CC: | lnykryn, msekleta, ngompa13, s, systemd-maint, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-01 13:08:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Verified the bug to be still present in Fedora 30. Relevant package versions: systemd-241-8.git9ef65cb.fc30.x86_64 *** This bug has been marked as a duplicate of bug 1197886 *** |
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?