Problems adding to targeted policy for a new cache directory for Squid

[Joe Cooper]

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 at 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 at localhost /]# ls -lZ /var/spool/squid
drwxr-xr-x  squid    squid    root:object_r:squid_cache_t      00
[root at 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 at localhost /]# ls -ldZ /var/spool/squid
drwxr-x---  squid    squid    system_u:object_r:squid_cache_t 
/var/spool/squid
[root at 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.  ;-)