I'm debugging a problem with rsyslogd on a CentOS 6.0 server (I'm not allowed to upgrade). While running the system in permissive mode I got the following entry in the audit log:

type=AVC msg=audit(1365002864.187:22167): avc: denied { search } for pid=27852 comm="rsyslogd" name="/" dev=md6 ino=2 scontext=unconfined_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir

Ok, so the rsyslog daemon is trying to access the root directory and gets denied. So far so good. What puzzles me is the target context that is being logged as default_t. Doing an "ls -ldZ /" produces the following output:

dr-xr-xr-x. root root system_u:object_r:root_t:s0 /

This indicates that the root directory has the context root_t. Why is this different from what's getting logged? Have I completely misunderstood anything about how SELinux contexts work? Does SELinux have an in-memory cache of file contexts, and this cache has become out of sync with the filesystem?

Tomorrow I will try to relabel the root directory to see if this helps. If there is a cache inconsistency maybe changing the context will fix the problem. A reboot is probably in order as well but I want to diagnose and understand the problem before I do that.

Has anyone seen this before?

Good questions but a machine running stock default targeted policy should come with proper constraints for syslogd_t already. If you semanage'd any custom local policies the right way a full relabel should correct things if nothing else happened you didn't tell us about. Note restorecon has a dry run switch so you can get an idea of the extent of changes before applying them.

restorecon has been run and didn't change anything. But the context of the root directory is already correct, it has the context root_t. Also, the policy for rsyslogd seems to permit the search operation for the target root_t. The problem is that SELinux logs error messages where it keeps denying access to the root directory and these log messages indicate that SELinux thinks the root directory has context default_t.

So why does SELinux in the kernel think that the root directory has context default_t, when "ls" says it has context root_t? These shouldn't differ.

Still I'm thinking something else happened you didn't tell us about: your syslog does run with a context of syslogd_t but as user unconfined_u while mine runs as system_u. What happens if you change Rsyslogd to run as system_u? Else :is this a CentOS stock installation? Was anything non-standard forced or did anything happen installation, policy or configuration-wise? Did this Rsyslogd get bolted on from another repo? BTW and why aren't you "allowed" to upgrade? CentOS is at 6u4 now and updates and upgrades may contain fixes.

The system runs an old CentOS 6.0 which hasn't been upgraded and I'm not allowed to upgrade the system, at least not right now.

But I think you're missing my point, or perhaps I wasn't clear in my original posting. I'm not asking about why the access gets denied or what I can do to fix it. What I want to know is why it appears as if the root directory has two different context labels. The "ls" command says that the context is the following:

system_u:object_r:root_t:s0

Yet the error message logged by SELinux says that the root directory has the following context:

system_u:object_r:default_t:s0

Why aren't those two the same?

Beats me. Prolly should ask on the selinux-devel mailing list.