Description of problem: Latest systemd in Rawhide calls initialize_security()/mac_selinux_setup() when reexecuting, while it did not do so before (I only checked Fedora 37, not sure which version started doing it). Looking at the current upstream code, it seems it is not intended (going by the skip_setup variable and early_skip_setup_check() in src/core/main.c). Doing mac_selinux_setup() while reexecuting triggers SELinux denials, since it is normally only called on early boot before policy is loaded and thus the policy wasn't being updated to allow init_t to do it for some time. Version-Release number of selected component (if applicable): systemd-253.2-1.fc39.x86_64 How reproducible: Always. Steps to Reproduce: 1. systemctl daemon-reexec Actual results: dmesg contains "systemd[1]: Failed to load new SELinux policy. Continuing with old policy." and there are SELinux denials in audit log. Expected results: No attempts to load SELinux policy by systemd on reexec.
*** Bug 2189416 has been marked as a duplicate of this bug. ***
See https://bugzilla.redhat.com/show_bug.cgi?id=2189416#c3
*** Bug 2203332 has been marked as a duplicate of this bug. ***
*** Bug 2203329 has been marked as a duplicate of this bug. ***
There were various fixes in this area recently, in particular https://github.com/systemd/systemd/commit/4f44d2c4f7. It's possible that we messed something up in the logic.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #5) > There were various fixes in this area recently, in particular > https://github.com/systemd/systemd/commit/4f44d2c4f7. > It's possible that we messed something up in the logic. Changing streq() to startswith() is at least a good start, so I just think this commit hasn't made it into rawhide and F38 before reporting. Still present in rawhide and F38 f38# rpm -q systemd systemd-253.4-1.fc38.x86_64 rawhide# rpm -q systemd systemd-253.4-1.fc39.x86_64
This doesn't seem to occur any more with systemd-253.5-6.fc39 (but probably was fixed earlier).