While messing around with xen, I set selinux to disabled in the /etc/selinux/config file so that I could build a xen guest image. Unthinkingly, I did an upgrade using yum while in selinux=disabled state. I later reset the config file to selinux=enforcing and rebooted. Oh boy was this a mistake. Needless to say, the reboot was completely unsuccessful past initstate 1. Recovering from this was quite a chore, and took several attempts. My final resolution was: 1. Reboot to initstate s 2. Change selinux mode to permissive, because restorecon cannot be executed in selinux=disabled mode. 3. Reboot, this time to initstate 3 so that selinux became active 4. run "restorecon -v -R /" 5. Now set selinux to enforcing in the config file 6. reboot for real This REALLY needs to be documented. It might be wise to have a kernel command line option that will be picked up in rc.sysinit EARLY in the init scripts (immediately after local FS mountall) that will cause restorecon to be run on the entire system at that point before any further bits of system initialization are run.. The fact that I was messing around with xen is really not the point. The point is that some dingbat out there will upgrade with selinux disabled and really regret it.
Hell. It's more of a nuisance than I thought. One actually needs to run restorecon -R -v / -e /misc -e /net or else one gets "operation not supported" on /misc, /net Which raises a question. Why don't restorecon /misc restorecon /net work?
Because they are file systems that do not support extented attributes. The best way to relabel is to touch /.autorelabel; reboot This is in the documentation. If you are going to run SELinux and you want to stop enforcing mode you can type setenforce 0 Then you could play with Xen. This will maintain the security contexts. If you want this to me maintained on reboot, set enforcing mode to permissive in /etc/selinux/config.
What file systems are you talking about? I think you did not read the bug report. Xen was incidental to this bug -- it was merely the thing that caused me to discover it. You can repeat this bug by: 1. Install FC3/FC4 from CD. Activate selinux during install. So far so good. 2. Disable selinux and reboot 3. Run yum update. 4. Renable selinux and reboot The problem here is not that the file system lacks the ability to support extended attributes. It is the same file system that the original selinux-enabled system was installed on in the first place. The problem is that chcon and friends did not operate during step 3 (and *could* not, since selinux was disabled). And yes, all of this is documented behavior, but that does not justify closing the bug. Think about the consequence in step 4: user now has an unbootable system. That is unquestionably a bug. Documenting it does not turn it into a feature. My concrete suggestion for how to address this is as follows: 1. Modify the system shutdown process to record whether selinux was running at the time of shutdown -- perhaps based on sestatus -v 2. On reboot, if selinux is NOW enabled and was not enabled at last shutdown, run restorecon very early in the reboot process.
Fixed in initscripts-8.11-1 Anytime you boot with selinux=0 it will create the /.autorelabel flag. Next time you boot with selinux enabled, it will relabel
I note that initscripts-8.11-1 is not yet in the devel tree. Is it anticipated to make the cut for FC4? Not that it matters - just idly curious. I think it's important to get this update out fairly soon, but it's definitely not a "hold the release" issue.
Looks like it will be in FC4.
Daniel: thank you for your efforts on this.