Bug 598874
Summary: | SELinux is preventing /sbin/setfiles access to a leaked /tmp/filey2SXJY file descriptor. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David <webmaster> |
Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 13 | CC: | dwalsh, mgrepl |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | setroubleshoot_trace_hash:eba2fe128efaa7c0e70c2bbc4e70b311b0d549a834e35278ed9b00a8f9192d2f | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-06-03 21:21:34 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
David
2010-06-02 09:11:43 UTC
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. |