I was monitoring a remote server (permissive mode) via sealert -b when setroubleshootd exited with this in /var/log/messages:
Did selinux deny setroubleshootd ?
gene
---------------------------------------------------- Jan 3 13:48:03 web1 setroubleshoot: [program.ERROR] setroubleshoot generated AVC, exiting to avoid recursion, context=system_u:system_r:setroubleshootd_t:s0, AVC scontext=system_u:system_r:setroubleshootd_t:s0 Jan 3 13:48:03 web1 setroubleshoot: [program.ERROR] audit event#012node=web1.prv.sapience.com type=AVC msg=audit(1231008483.779:1387): avc: denied { signull } for pid=265 9 comm="setroubleshootd" scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=unconf ined_u:unconfined_r:unconfined_t:s0 tclass=process#012#012node=web1.prv.sapience.com type=SYSCALL msg=audit(1231008483.779:1387): arch=40000003 syscall=37 success=yes exit=0 a0=2079 a1=0 a2=ad454c a3=2079 items=0 ppid=1 pid=2659 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setroubleshootd" exe=2F7573722F62696E2F707974686F6E2E237072656C696E6B23202864656C6574656429 subj=system_u: system_r:setroubleshootd_t:s0 key=(null)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mail Lists wrote:
I was monitoring a remote server (permissive mode) via sealert -b when setroubleshootd exited with this in /var/log/messages:
Did selinux deny setroubleshootd ?
gene
Jan 3 13:48:03 web1 setroubleshoot: [program.ERROR] setroubleshoot generated AVC, exiting to avoid recursion, context=system_u:system_r:setroubleshootd_t:s0, AVC scontext=system_u:system_r:setroubleshootd_t:s0 Jan 3 13:48:03 web1 setroubleshoot: [program.ERROR] audit event#012node=web1.prv.sapience.com type=AVC msg=audit(1231008483.779:1387): avc: denied { signull } for pid=265 9 comm="setroubleshootd" scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=unconf ined_u:unconfined_r:unconfined_t:s0 tclass=process#012#012node=web1.prv.sapience.com type=SYSCALL msg=audit(1231008483.779:1387): arch=40000003 syscall=37 success=yes exit=0 a0=2079 a1=0 a2=ad454c a3=2079 items=0 ppid=1 pid=2659 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setroubleshootd" exe=2F7573722F62696E2F707974686F6E2E237072656C696E6B23202864656C6574656429 subj=system_u: system_r:setroubleshootd_t:s0 key=(null)
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
setroubleshoot will die if it finds an AVC about it self to prevent an infinite loop of avcs.
setroubleshoot can send itself a signull on both Rawhide and F10 with the latest updates.
On 01/04/2009 02:40 PM, Daniel J Walsh wrote:
setroubleshoot will die if it finds an AVC about it self to prevent an infinite loop of avcs.
setroubleshoot can send itself a signull on both Rawhide and F10 with the latest updates.
What caused it to have a problem ? Is this expected behaviour for setroubleshootd - or is something amiss that caused it to get the signull ?
Do I need to write a monitor script to keep restarting it ?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mail Lists wrote:
On 01/04/2009 02:40 PM, Daniel J Walsh wrote:
setroubleshoot will die if it finds an AVC about it self to prevent an infinite loop of avcs.
setroubleshoot can send itself a signull on both Rawhide and F10 with the latest updates.
What caused it to have a problem ? Is this expected behaviour for setroubleshootd - or is something amiss that caused it to get the signull ?
Do I need to write a monitor script to keep restarting it ?
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
No it is probably just a bug in policy.
setroubleshoot executes a lot of code to try to figure out what caused an AVC, so sometimes a new code path is crossed which we did not write policy for.
selinux@lists.fedoraproject.org