Hide Forgot
Description of problem: After resume from hibernation (if important) time->Wed Apr 4 17:34:11 2012 type=AVC msg=audit(1333553651.616:318): avc: denied { write } for pid=3858 comm="systemd" name="/" dev="sda3" ino=2 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Version-Release number of selected component (if applicable): klaus@acer:~$ rpm -qa selinux\*;rpm -qa systemd\* selinux-policy-3.10.0-80.fc16.noarch selinux-policy-targeted-3.10.0-80.fc16.noarch systemd-37-17.fc16.i686 systemd-units-37-17.fc16.i686 systemd-sysv-37-17.fc16.i686 How reproducible: This came after the last update Additional info: System uses confined users, but up to now this message did not show up
Does the AVC message have an associated SYSCALL message with the same timestamp in /var/log/audit/audit.log? If yes, could you paste it?
No, I did check. Looking into audit.log I find the following two entries with matching timestamps: type=SERVICE_STOP msg=audit(1333553651.568:316): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="atd" exe="/bin/systemd" hostname=? addr=? terminal=? res=success' type=ANOM_ABEND msg=audit(1333553651.615:317): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:init_t:s0 pid=3858 comm="systemd" reason="memory violation" sig=11
So, is the write access... a core dump?
Hmm, looks like you managed to get systemd to crash. I'd be really interested in getting a backtrace for that...
Hi, yes, obviously it's a core dump, or at least trying to core dump. I tried to get all messages that I could find relevant to this. It looks like this didn't happen since Apr 4. I don't know why, as I can't find any relevant update around this time. What I could find is: type=SERVICE_STOP msg=audit(1333553651.568:316): pid=0 uid=0 auid=4294967295 ses =4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="atd" exe="/bin/systemd" hostname=? addr=? terminal=? res=success' type=ANOM_ABEND msg=audit(1333553651.615:317): auid=4294967295 uid=0 gid=0 ses=4 294967295 subj=system_u:system_r:init_t:s0 pid=3858 comm="systemd" reason="memor y violation" sig=11 type=AVC msg=audit(1333553651.616:318): avc: denied { write } for pid=3858 comm="systemd" name="/" dev="sda3" ino=2 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Correlating to messages: Apr 4 17:34:11 acer dbus[867]: [system] Successfully activated service 'org.freedesktop.PackageKit' Apr 4 17:34:11 acer dbus-daemon[867]: dbus[867]: [system] Successfully activated service 'org.freedesktop.PackageKit' Apr 4 17:34:11 acer kernel: [ 7064.570122] systemd[1]: segfault at f11 ip 08084010 sp bfe309d0 error 6 in systemd[8048000+d8000] Apr 4 17:34:11 acer systemd[1]: Caught <SEGV>, core dump failed. Apr 4 17:34:11 acer systemd[1]: Freezing execution. I guess I was running in enforcing then. I tried to recreate this with permissive, but this does not happen again at the moment, but there's a handful of new avc's. I'll add this in the attachment. Basically, systemd is not allowed to do some things at startup. There are different denials with enforcing and permissive. Klaus
Created attachment 576841 [details] denials after boot in permissive mode
Created attachment 576842 [details] denials after boot in enforcing mode
Just to clarify: the original message for the bug was from thawing after hibernation, the attachment are from a fresh boot. Right now it looks like I have no denials from resuming, as far as I can tell, don't know whether I can catch all messages
The crash after hibernation could have been due to a kernel bug and the resulting memory corruption.
I'm going with the theory of memory corruption at hibernation and closing this as CANTFIX. If there were a reliable reproducer, the kernel maintainers might be able to do something about it. Otherwise there's little we can do. If you're still seeing AVC denials during fresh boot with the latest updates, please report them against selinux-policy.