On 06/15/2009 06:31 PM, Scott Radvan wrote:
On Mon, 15 Jun 2009 07:19:39 +0100 Paul Howarthpaul@city-fan.org wrote:
On Mon, 15 Jun 2009 13:47:08 +1000 Scott Radvansradvan@redhat.com wrote:
I got a denial when actually starting squid for the first time (I assume this happens as it attempts to create its pid in /var/run):
What's happening here is a denial for *reading* /var/run/squid.pid, which is of type var_run_t. Now in Fedora 11 this file should be labelled squid_var_run_t, and that's what it is labelled on two Fedora 11 boxes freshly installed here. It seems there's a labelling problem on your system. Can you post the output of "ls -lZa /var/run"? Is your system a fresh install or an upgrade?
Paul.
I'm pretty sure I've figured out what I was doing wrong after another re-install.
I was previously starting squid directly from /usr/sbin/squid instead of using 'service squid start'. Starting it directly from /usr/sbin/squid apparently(?) doesn't initialise squid.pid as squid_var_run_t, rather it just starts as var_run_t, which is why I got a denial.
Starting squid via 'service squid start' as I should have been doing from the start is working fine now. Thanks for your help Paul.
Unconfined processes tend to stay unconfined. That is what uses expect, telling them that they are executing an uconfined process that suddenly becomes confined, seems wrong to them. That being said, you can end up with mislabeled files because of this.
So
unconfined_t -> squid_exec_t -> unconfined_t
But unconfined processes starting init scripts have a transition
unconfined_t -> initrc_exec_t -> initrc_t -> squid_exec_t -> squid_t
So any time you are using a confined process you should use the init script to start them, otherwise you could get mislabeled files.