Joe Cooper wrote:
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
Just to add to this, I found an update in the testing directory for policycoreutils that fixes this segfault, so this aspect of the problem goes away. However, I'm still losing the label on swap.state, and I've also noticed that I'm actually getting slightly different labels than /var/spool/squid:
[root@localhost /]# ls -lZ /var/spool/squid drwxr-xr-x squid squid root:object_r:squid_cache_t 00 [root@localhost /]# ls -lZ /cache0 drwxr-xr-x squid squid system_u:object_r:squid_cache_t 00
So I've got root:object_r:squid_cache_t for /var/spool/squid (the one that works) and system_u:object_r:squid_cache_t for the one that doesn't, though the top level directory of /var/squid/squid is the same:
[root@localhost /]# ls -ldZ /var/spool/squid
drwxr-x--- squid squid system_u:object_r:squid_cache_t /var/spool/squid
[root@localhost /]# ls -ldZ /cache0
drwxr-xr-x squid squid system_u:object_r:squid_cache_t /cache0
I have no clue where that root/system_u difference is coming from--I never have been able to figure out how this labeling happens.
Thanks for any clarification anyone might have for me. My first foray into SELinux has been a harrowing experience...a week in and I still have only foggy notions of what's happening. ;-)
