I updated my laptop to rawhide a while back and selinux has been more or less OK. I patched it a few days ago however and somehow /lib/ld-2.10.90.so ended up with a context of system_u:object_r:tmp_t:s0.
At the time, I wasn't sure what was wrong other than that selinux was borked and disabling it allowed the machine to boot. So I booted with "autorelabel" set. fixfiles crawled the fs, but didn't fix the label on /lib/ld-2.10.90.so.
Eventually, I figured out what was broken and ran restorecon on it by hand and it seemed to be OK.
I can reproduce this at will though. If I change the security context of /lib/ld-2.10.90.so and then boot with autorelabel, it doesn't fix its label. It also doesn't fix it if I run:
# fixfiles -F restore
...from the command line when the laptop is booted in permissive mode. If I run this though:
# fixfiles -F restore /lib
...it does fix it.
Actually, the problem is a little worse. fixfiles -F restore is actually setting the context of /lib/ld-2.10.90.so to tmp_t, even when it was correct before.
Running fixfiles -F check doesn't show any changes for this file, so it's not clear to me why it's forcing this change. Let me know if there's any info you need to troubleshoot this. The machines is a fairly up to date F12 install. I don't think I have any custom selinux configuration either.
Ouch, it's even worse...
# fixfiles check
resets the context of that file to tmp_t as well. Note that it might be resetting others too that I haven't noticed.
ls -l /lib/ld-2.10.90.so
Also, mount | grep bind
# ls -l /lib/ld-2.10.90.so
-rwxr-xr-x. 1 root root 188200 2009-09-21 07:24 /lib/ld-2.10.90.so
# mount | grep bind
# grep bind /proc/mounts
...also no output
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
Seems to be working correct now.