Bug 174618

*complete guess*, the policy in FC5t1 has set attributes that the FC4 kernel
doesn't know about. 

Doing a relabel in FC4 should fix things I think.  Dan ?

Any avc messages generated?  rpm should be allowed to do this. 

Try it with 
setenforce 0
And see if it works.

Yup, setenforce 0 solves the problem. I saw no AVC messages on the console or in
/var/log/messages, but there are some messages referencing /dev/sda1 (/boot):

 Nov 30 19:04:53 deanna kernel: inode_doinit_with_dentry: 
context_to_sid(system_u:object_r:boot_t:s0) returned 22 for dev=sda1 ino=123521
Nov 30 19:04:53 deanna kernel: inode_doinit_with_dentry: 
context_to_sid(system_u:object_r:boot_t:s0) returned 22 for dev=sda1 ino=27
Nov 30 19:04:53 deanna kernel: inode_doinit_with_dentry: 
context_to_sid(system_u:object_r:boot_t:s0) returned 22 for dev=sda1 ino=24
Nov 30 19:04:53 deanna kernel: inode_doinit_with_dentry: 
context_to_sid(system_u:object_r:boot_t:s0) returned 22 for dev=sda1 ino=26
Nov 30 19:04:53 deanna kernel: inode_doinit_with_dentry: 
context_to_sid(system_u:object_r:system_map_t:s0) returned 22 for dev=sda1 ino=23
Nov 30 19:04:53 deanna kernel: inode_doinit_with_dentry: 
context_to_sid(system_u:object_r:boot_t:s0) returned 22 for dev=sda1 ino=25

This looks like you had some kind of labeling problem.

Did you relabel one machine while the others disk partion was mounted?

You can relabel, 
touch /.autorelabel; reboot
, but make sure the FC5 disk is not mounted.

No, I certainly did not relabel anything. Maybe the FC5T1 installer mounted my
FC4 / partition and did relabel during install?

After "touch /.autorelabel ; reboot" in FC4 I now can again write to /boot
without the need to "setenforce 0".

FC5 turns on the MLS support in SELinux, so file security contexts now have a
MLS field (being used for the MCS policy there by default).  A compatibility
patch went upstream to allow non-MLS kernels to gracefully handle file security
contexts that have the MLS field, but likely isn't in the FC4 kernel yet. I'll
attach it to this bug report momentarily.

Created attachment 121679 [details]
MLS compatibility patch for SELinux, included in 2.6.15-rcX

thanks, I've merged it into CVS, it'll be in the next update.

Now I'm up to FC5T2 and I'm running into the same problem again. This time /boot
is shared between FC5T2, FC4, Centos 4.2. After FC5T2 has been installed I tried
to update the Centos 4.2 kernel to 2.6.9-22.0.2 (which is effectively the same
as the RHES 4.2 errata kernel). We're getting a big problem here as other
Selinux enabled distributions won't be able to access /boot anymore.

See Bug 177439 for proposed fix for RHEL4 kernel.

Even with this fix included you have to make sure that you update your RHES4
kernel before installing FC5 and even more worse this only works for Red Hat
alike distributions. All other Selinux enabled distributions that don't have
this fix will this break when trying to update a kernel if you have a shared
/boot partition.

There is always the setenforce 0 option for recovery.

dual booting different releases and sharing partitions this way is always going
to be problematic.  It's such a pathological case, that I think disabled selinux
is really the only way to ensure pain free co-existance.

Whilst I'll go out of my way to try and make sure that FC4 can read FC5
filesystems, there's always going to be a lag until I have updates out, likewise
any necessary policy changes.

Sharing /boot between different releases is a pretty bizarre thing to want to do
anyway, as kernels are closely tied to various parts of the system for correct
operation, such as udev.

The current FC4 update kernel has the MLS patch so things should be fine now.