Hide Forgot
Description of problem: If selinux-policy-3.10.0-114, selinux-policy-targeted-3-10.0-114 are installed, my machine does not enter standby mode when power button is pressed or standby is requested via menu. Standby works if I downgrade the said components to 3.10.0-110. Selinux mode at the moment is 'permissive'. There are no avc's (only one from firefox that was not allowed to ptrace). Version-Release number of selected component (if applicable): selinux-policy-3.10.0-114.fc17.noarch selinux-policy-targeted-3.10.0-110.fc17.noarch How reproducible: Always Steps to Reproduce: 1.Install said packages 2.Press power button 3. Actual results: Machin does not enter standby mode, looks more like a screensaver screen, network is down. alt-sysrq and REI, does bring back the machine to compplete service. Expected results: Machine does enter standby mode. Additional info:
the version of selinux-policy-targeted is actually also 3.10.0-114, the one I entered above was a mistake
And what does $ ausearch -m user_avc
ausearch -m user_avc ---- time->Sat Mar 17 13:29:41 2012 type=USER_AVC msg=audit(1331987381.932:80): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.colord.sane member=Refresh dest=org.freedesktop.colord-sane spid=2772 tpid=2785 scontext=system_u:system_r:colord_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' ---- time->Sun Mar 18 10:29:14 2012 type=USER_AVC msg=audit(1332062954.703:63): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.colord.sane member=Refresh dest=org.freedesktop.colord-sane spid=1337 tpid=1341 scontext=system_u:system_r:colord_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' ---- time->Tue Mar 20 22:50:28 2012 type=USER_AVC msg=audit(1332280228.846:44): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.colord.sane member=Refresh dest=org.freedesktop.colord-sane spid=1361 tpid=1383 scontext=system_u:system_r:colord_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
Any idea what service is running as initrc_t? ps -eZ | grep initrc_t?
I am just trying to find what is wrong.
Does it work for you in permissive mode?
ps -eZ | grep initrc_t system_u:system_r:initrc_t:s0 542 ? 00:00:00 abrt-watch-log no permissive mode does not work.
In this case, this is not SELinux issue. We know about abrt-watch-log.
disabling selinux does work, but that's not what I want. So if selinux is not the problem, why does it occur if I only update the selinux policy? What do I need to do to solve the issue? I have this behaviour on two machines, my main desktop which is x86_64 and a ten year old notebook that is i686. One machine is running gnome and the other KDE, but both show the same symtoms. At the olde machine I can install anything you want for debugging, it is not used other than testing. Thanks
Are you up-to-date? $ rpm -q gdm
Yes I update daily. gdm-3.4.1-1.fc17.i686 I can disable the abrtd service, if that helps
dbus does not necessarily follow permissive mode, for now add a custom policy module to allow the dbus messages and see if that makes it work. grep dbus /var/log/audit/audit.log | audit2allow -M mydbus semodule -i mydbus.pp I think some app is being launched as shutdown and we run it as initrc_t, but when we later look it is disappeared. Although I have no idea why colord would be involved in suspend/shutdown.
grep dbus /var/log/audit/audit.log | audit2allow -M mydbus semodule -i mydbus.pp did not change the behaviour. I can empty the audit log, press the standby button and attach the resulting audit.log, so that you can have a look at it. At the testing machine the mode is set to enforcing, but there is not gdm but kdm runinning.
I did 'ausearch -m avc -ts recent' that showed nothing. Then I executed 'semodule -DB', triggered a standby and executed again 'ausearch -m avc -ts recent' that gave me: time->Wed Apr 18 22:17:30 2012 type=AVC msg=audit(1334780250.242:51): avc: denied { siginh } for pid=1524 comm="nm-dispatcher.a" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=process ---- time->Wed Apr 18 22:17:30 2012 type=AVC msg=audit(1334780250.242:50): avc: denied { rlimitinh } for pid=1524 comm="nm-dispatcher.a" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=process ---- time->Wed Apr 18 22:17:30 2012 type=AVC msg=audit(1334780250.274:52): avc: denied { noatsecure } for pid=1524 comm="nm-dispatcher.a" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=process ---- time->Wed Apr 18 22:17:39 2012 type=AVC msg=audit(1334780259.753:56): avc: denied { siginh } for pid=1696 comm="fprintd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fprintd_t:s0-s0:c0.c1023 tclass=process ---- time->Wed Apr 18 22:17:39 2012 type=AVC msg=audit(1334780259.763:57): avc: denied { noatsecure } for pid=1696 comm="fprintd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fprintd_t:s0-s0:c0.c1023 tclass=process ---- time->Wed Apr 18 22:17:39 2012 type=AVC msg=audit(1334780259.753:55): avc: denied { rlimitinh } for pid=1696 comm="fprintd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fprintd_t:s0-s0:c0.c1023 tclass=process Does that help you?
the problem is gone with selinux-policy-3.10.0-116.fc17.noarch