Joe Cooper wrote:
The newer versions of restorecon allow you to specify file_contexts.local for things like this so you don't have to deal with sources.Hi all,
I'm running into some issues adding policy to cover some extra directories that we use on our systems. I'm using FC3 and the latest errata targeted policy and kernel. For our Squid process, we devote one or more partitions for cache storage, named /cache0, /cache1, and so on.
I've added the following line to file_contexts/program/squid.fc:
/cache.*(/.*)? system_u:object_r:squid_cache_t
Which matches the lines for /var/spool/squid(/.*)? and /var/cache/squid(/.*)?. After running "restorecon -Rv /cache0", I have the right label on /cache0:
[root@localhost /]# ls -ldZ /cache0
drwxr-xr-x squid squid system_u:object_r:squid_cache_t /cache0
[root@localhost /]# ls -ldZ /var/spool/squid
drwxr-x--- squid squid system_u:object_r:squid_cache_t /var/spool/squid
However, when I start Squid I get a lot of avc: denied errors (I'm in permissive mode for testing). Some of which don't even make any sense to me, like this one:
audit(1108452395.149:0): avc: denied { read } for pid=3778 exe=/usr/sbin/squid name=00 dev=hdc2 ino=5 scontext=root:system_r:squid_t tcontext=root:object_r:nfs_t tclass=dir
This seems to indicate Squid needs to have nfs_t privileges, though I don't see why this should be so in the targeted policy.
Yes it should not need this.
If I run restorecon again (after creating the directories), I get a segfault and it stops before reaching the file(s) in the top level of the directory (there are subdirectories which all get relabeled). i.e.:
[root@localhost /]# restorecon -Rv /cache0 ... restorecon reset context /cache0/0F/FF:->system_u:object_r:squid_cache_t Segmentation fault [root@localhost /]# ls -lZ /cache0 drwxr-xr-x squid squid system_u:object_r:squid_cache_t 00 drwxr-xr-x squid squid system_u:object_r:squid_cache_t 01 drwxr-xr-x squid squid system_u:object_r:squid_cache_t 02 drwxr-xr-x squid squid system_u:object_r:squid_cache_t 03 drwxr-xr-x squid squid system_u:object_r:squid_cache_t 04 drwxr-xr-x squid squid system_u:object_r:squid_cache_t 05 drwxr-xr-x squid squid system_u:object_r:squid_cache_t 06 drwxr-xr-x squid squid system_u:object_r:squid_cache_t 07 drwxr-xr-x squid squid system_u:object_r:squid_cache_t 08 drwxr-xr-x squid squid system_u:object_r:squid_cache_t 09 drwxr-xr-x squid squid system_u:object_r:squid_cache_t 0A drwxr-xr-x squid squid system_u:object_r:squid_cache_t 0B drwxr-xr-x squid squid system_u:object_r:squid_cache_t 0C drwxr-xr-x squid squid system_u:object_r:squid_cache_t 0D drwxr-xr-x squid squid system_u:object_r:squid_cache_t 0E drwxr-xr-x squid squid system_u:object_r:squid_cache_t 0F -rw-r--r-- squid squid swap.state
So swap.state is still unlabeled, and starting Squid leads to more avc: denied errores. If I restorecon on just swap.state, Squid starts without errors, but after a reboot, the label is lost and Squid generates errors again. I'll file an issue on the restorecon segfault, but that still probably doesn't solve all of my problems.
So, I'm quite stumped...I thought I had done what I needed to make this work, but clearly there's at least three things I don't understand:
1. Why does it lose the swap.state label on reboot? Does restorecon run on every boot?
Does /cache0 get deleted on reboot? Is this on an ext3 file system?
2. Why doesn't /var/spool/squid exhibit this same problem? restorecon works without segfault, and doesn't lose the label on swap.state after a reboot.restorecon fixed in update.
The only way you should loose the context is if you are using something other than ext2/3 for a file system or if the directory is being replaced
on every reboot.
3. Where is nfs_t coming from on /cache0? It seems like some kind of default that it falls back to when a file is unlabeled, but I don't see anywhere that nfs_t is a generic label.I don't know, Are you starting the squid service while sitting on an NFS partition? Any directories having anything to do with Squid on an NFS partition?
Thanks!
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
