Red Hat Bugzilla – Bug 156765
upgrade with selinux disabled borks file contexts
Last modified: 2007-11-30 17:11:05 EST
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
Needless to say, the reboot was completely unsuccessful past initstate 1.
Recovering from this was quite a chore, and took several attempts. My final
1. Reboot to initstate s
2. Change selinux mode to permissive, because restorecon cannot be executed in
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
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
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
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
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
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
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
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.