I'm running into some weird behavior on a RHEL5 system and I'm not sure if it's related to selinux or not. The behavior began after rebooting the system to switch to a different selinux policy. This same policy has been installed on other systems without issue. The /etc/selinux/config file was set to put the policy into permissive mode upon reboot. After the initial reboot, and each time after several subsequent reboots, we've come across files which can not be read, by both root and ordinary users. These files can not be read even in permissive mode. For example, I could not read a csh script file that was owned by user m2, with permissions of 764. I could not read this file as either user m2 or root, with the policy in permissive mode. However, I used chmod to change the permissions of the file to 777, and then could read it. Using chmod to put it back to 764, I could still read the file as expected. I have no idea what was preventing me from initially reading the file. The same thing happened to another user after a different reboot with a property file. Similar to what I described above, the user could not read the file in permissive mode even though the DAC permissions appeared as though it should have allowed him to do so. In that case the user was able to move the file to a different directory and then could read it, which makes no sense. Each time we reboot this problem afflicts different files. One time I found I could not use the ps command because I could not read /bin/ps. During each reboot I've been careful to make sure that an empty /.autorelabel file existed to make sure the filesystem remained in a consistent state. I have found no selinux labeling issues with the files that have had these problems. This last time I was forced to reboot because I found that I could not start the auditd daemon, which of course makes it difficult to troubleshoot any selinux AVC denials. I couldn't start this in either enforcing or permissive mode, but had no problems starting it after the reboot. Any ideas on what may be going on would be greatly appreciated. Thanks -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
