From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9) Gecko/20071105 Fedora/2.0.0.9-1.fc8 Firefox/2.0.0.9 Description of problem: Sorry if this isn't clear. I was helped significantly by the #selinux IRC channel. Started with a report: avc: denied { getattr } for comm=tmpwatch dev=sda2 egid=0 euid=0 exe=/usr/sbin/tmpwatch exit=0 fsgid=0 fsuid=0 gid=0 items=0 path=/tmp/acroread_500_500 pid=4246 scontext=system_u:system_r:tmpreaper_t:s0 sgid=0 subj=system_u:system_r:tmpreaper_t:s0 suid=0 tclass=dir tcontext=system_u:object_r:file_t:s0 tty=(none) uid=0 Seems that /tmp has no default sstatus set. Acrobat reader uses /tmp/acroread_500_500 for some purpose unknown to me. Appears that directory has been there some time. restorecon -R -v /tmp seems not to have done what it should. Running acroread again caused the same problem. ls -alZ /tmp | grep file_t drwxr-xr-x dpawson dpawson system_u:object_r:file_t acroread_500_500 Deleting the directory (/tmp/acroread_500_500) seems to have resolved the problem. the selinux management tool shows both /tmp and /sys as having file context as <<none>> Hope that's enough to help you figure out what's happening. Version-Release number of selected component (if applicable): selinux-policy-devel-3.0.8-53.fc8, selinux-policy-3.0.8-53.fc8 selinux-policy-3.0.8-53.fc8 How reproducible: Always Steps to Reproduce: 1. run acrobat reader 2. view the selinux status of /tmp/acroread_500_500 directory 3. Actual Results: Expected Results: No reports of 'denial' wanted. Please. Additional info:
The /tmp directory is a difficult directory since any file name can be placed there. So having a unlabeled file there, is going to be a problem. You could have used chcon -t tmp_t /tmp/acroread_500_500 to set the file context but there restorecon has no idea what to label the file.