Description of problem: It makes much more sense when the PID file is labelled cachefilesd_var_run_t, because it is located in /var/run and it is created by the daemon. Version-Release number of selected component (if applicable): selinux-policy-mls-3.7.19-155.el6_3.2.noarch selinux-policy-doc-3.7.19-155.el6_3.2.noarch selinux-policy-3.7.19-155.el6_3.2.noarch selinux-policy-targeted-3.7.19-155.el6_3.2.noarch selinux-policy-minimum-3.7.19-155.el6_3.2.noarch How reproducible: always Steps to Reproduce: # service cachefilesd status cachefilesd is stopped # service cachefilesd start Starting cachefilesd: [ OK ] # restorecon -Rv /var restorecon reset /var/run/cachefilesd.pid context unconfined_u:object_r:cachefilesd_var_run_t:s0->unconfined_u:object_r:cachefiles_var_t:s0 # ls -Z /var/run/cachefilesd.pid Actual results: -rw-r--r--. root root unconfined_u:object_r:cachefiles_var_t:s0 /var/run/cachefilesd.pid Expected results: -rw-r--r--. root root unconfined_u:object_r:cachefilesd_var_run_t:s0 /var/run/cachefilesd.pid
We did not write this policy. But it looks like as a bug.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0314.html