Summary: SELinux is preventing /sbin/setfiles access to a leaked /tmp/filey2SXJY file descriptor. Detailed Description: [restorecon has a permissive type (setfiles_t). This access was not denied.] SELinux denied access requested by the restorecon command. It looks like this is either a leaked descriptor or restorecon output was redirected to a file it is not allowed to access. Leaks usually can be ignored since SELinux is just closing the leak and reporting the error. The application does not use the descriptor, so it will run properly. If this is a redirection, you will not get output in the /tmp/filey2SXJY. You should generate a bugzilla on selinux-policy, and it will get routed to the appropriate package. You can safely ignore this avc. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Additional Information: Source Context system_u:system_r:setfiles_t:s0 Target Context system_u:object_r:initrc_tmp_t:s0 Target Objects /tmp/filey2SXJY [ file ] Source restorecon Source Path /sbin/setfiles Port <Unknown> Host (removed) Source RPM Packages policycoreutils-2.0.82-18.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-22.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name leaks Host Name (removed) Platform Linux (removed) 2.6.33.5-112.fc13.i686.PAE #1 SMP Thu May 27 02:56:20 UTC 2010 i686 i686 Alert Count 2 First Seen Wed 02 Jun 2010 07:08:59 PM EST Last Seen Wed 02 Jun 2010 07:08:59 PM EST Local ID eb99ee55-48f5-43eb-992c-89416460d507 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1275469739.189:11): avc: denied { write } for pid=2672 comm="restorecon" path="/tmp/filey2SXJY" dev=dm-0 ino=5848 scontext=system_u:system_r:setfiles_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file node=(removed) type=AVC msg=audit(1275469739.189:11): avc: denied { write } for pid=2672 comm="restorecon" path="/tmp/filey2SXJY" dev=dm-0 ino=5848 scontext=system_u:system_r:setfiles_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1275469739.189:11): arch=40000003 syscall=11 success=yes exit=0 a0=9e8b260 a1=9e8aba8 a2=9e6ae50 a3=9e8aba8 items=0 ppid=2638 pid=2672 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="restorecon" exe="/sbin/setfiles" subj=system_u:system_r:setfiles_t:s0 key=(null) Hash String generated from leaks,restorecon,setfiles_t,initrc_tmp_t,file,write audit2allow suggests: #============= setfiles_t ============== allow setfiles_t initrc_tmp_t:file write;
This looks like a service is running as initrc_t and redirecting output to a tmp file. Puppet? ps -eZ | grep initrc_t
[root@primary ~]# ps -eZ | grep initrc_t system_u:system_r:initrc_t:s0 2351 ? 00:00:00 asl-httpd system_u:system_r:initrc_t:s0 2368 ? 00:00:00 asl-httpd system_u:system_r:initrc_t:s0 2508 ? 00:00:02 restart-httpd.p system_u:system_r:initrc_t:s0 2551 ? 00:00:00 ossec-dbd system_u:system_r:initrc_t:s0 2555 ? 00:00:00 ossec-maild system_u:system_r:initrc_t:s0 2559 ? 00:00:00 ossec-execd system_u:system_r:initrc_t:s0 2563 ? 00:00:46 ossec-analysisd system_u:system_r:initrc_t:s0 2567 ? 00:00:00 ossec-logcollec system_u:system_r:initrc_t:s0 2578 ? 00:01:27 ossec-syscheckd system_u:system_r:initrc_t:s0 2582 ? 00:00:00 ossec-monitord system_u:system_r:initrc_t:s0 5884 ? 00:00:00 psmon
I would figure one of those scripts is doing some kind of command like restorecon FILE > /tmp/file... grep restorecon /etc/init.d/*
Hi Daniel, [root@primary ~]# grep restorecon /etc/init.d/* /etc/init.d/livesys: [ -x /sbin/restorecon ] && /sbin/restorecon /home /etc/init.d/livesys:[ -x /sbin/restorecon ] && /sbin/restorecon /var/cache/yum /tmp /var/tmp >/dev/null 2>&1 /etc/init.d/mysqld: [ -x /sbin/restorecon ] && /sbin/restorecon "$errlogfile" /etc/init.d/mysqld: [ -x /sbin/restorecon ] && /sbin/restorecon "$datadir" /etc/init.d/restorecond:# restorecond: Daemon used to maintain path file context /etc/init.d/restorecond:# description: restorecond uses inotify to look for creation of new files \ /etc/init.d/restorecond:# listed in the /etc/selinux/restorecond.conf file, and restores the \ /etc/init.d/restorecond:# processname: /usr/sbin/restorecond /etc/init.d/restorecond:# config: /etc/selinux/restorecond.conf /etc/init.d/restorecond:# pidfile: /var/run/restorecond.pid /etc/init.d/restorecond:test -x /usr/sbin/restorecond || exit 5 /etc/init.d/restorecond:test -f /etc/selinux/restorecond.conf || exit 6 /etc/init.d/restorecond: echo -n $"Starting restorecond: " /etc/init.d/restorecond: daemon /usr/sbin/restorecond /etc/init.d/restorecond: touch /var/lock/subsys/restorecond /etc/init.d/restorecond: echo -n $"Shutting down restorecond: " /etc/init.d/restorecond: killproc restorecond /etc/init.d/restorecond: rm -f /var/lock/subsys/restorecond /etc/init.d/restorecond: status restorecond /etc/init.d/restorecond: [ -e /var/lock/subsys/restorecond ] && restart || : /etc/init.d/sendmail: /sbin/restorecon /var/run/sm-client.pid /etc/init.d/sshd: if [ -x /sbin/restorecon ]; then /etc/init.d/sshd: /sbin/restorecon $RSA1_KEY.pub /etc/init.d/sshd: if [ -x /sbin/restorecon ]; then /etc/init.d/sshd: /sbin/restorecon $RSA_KEY.pub /etc/init.d/sshd: if [ -x /sbin/restorecon ]; then /etc/init.d/sshd: /sbin/restorecon $DSA_KEY.pub /etc/init.d/vncserver: restorecon /tmp/.X11-unix 2>/dev/null || :
Those look fine. Has this happened again? I still think this is something to do with an yum update. If it happens again please reopen bug.