Bug 174618 - Can't update FC4 kernel on a dual FC4 / FC5T1 system with shared /boot
Can't update FC4 kernel on a dual FC4 / FC5T1 system with shared /boot
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-30 13:40 EST by Bernd Bartmann
Modified: 2015-01-04 17:23 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-19 01:13:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
MLS compatibility patch for SELinux, included in 2.6.15-rcX (1.23 KB, patch)
2005-12-01 07:20 EST, Stephen Smalley
no flags Details | Diff

  None (edit)
Description Bernd Bartmann 2005-11-30 13:40:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
Some days ago I installed FC5T1 parallel to FC4 on my hdd.
/dev/sda1 is mounted as /boot for both FC4 and FC5T1
/dev/sda5 is / for FC4
/dev/sda6 is / for FC5T1

Now when I'm in FC4 and try to update to the new errata kernel-2.6.14-1.1644_FC4 I get:
Error: unpacking of archive failed on file /boot/System.map-2.6.14-1.1644_FC4;438df1f6: cpio: open failed - no permission

All other FC4 updates beside the kernel went without any problem. In fact any write access to /boot fails. So I guess that FC5T1 somehow set some selinux rules on /boot.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. have a dual boot FC4 / FC5T1 system with a shared /boot
2. after installing FC5T1 start FC4
3. try to write a file to /boot
  

Additional info:
Comment 1 Dave Jones 2005-11-30 13:47:39 EST
*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 ?

Comment 2 Daniel Walsh 2005-11-30 13:58:00 EST
Any avc messages generated?  rpm should be allowed to do this. 

Try it with 
setenforce 0
And see if it works.
Comment 3 Bernd Bartmann 2005-11-30 14:18:36 EST
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

Comment 4 Daniel Walsh 2005-11-30 14:40:10 EST
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.

Comment 5 Bernd Bartmann 2005-11-30 15:04:54 EST
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".
Comment 6 Stephen Smalley 2005-12-01 07:16:16 EST
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.
Comment 7 Stephen Smalley 2005-12-01 07:20:52 EST
Created attachment 121679 [details]
MLS compatibility patch for SELinux, included in 2.6.15-rcX
Comment 8 Dave Jones 2005-12-02 01:04:38 EST
thanks, I've merged it into CVS, it'll be in the next update.
Comment 9 Bernd Bartmann 2006-01-18 15:01:32 EST
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.
Comment 10 Stephen Smalley 2006-01-18 15:13:01 EST
See Bug 177439 for proposed fix for RHEL4 kernel.
Comment 11 Bernd Bartmann 2006-01-18 15:24:05 EST
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.
Comment 12 Stephen Smalley 2006-01-18 15:34:11 EST
There is always the setenforce 0 option for recovery.
Comment 13 Dave Jones 2006-01-19 01:13:25 EST
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.

Note You need to log in before you can comment on or make changes to this bug.