Bug 243447 - Second linux install is destroyed by Selinux change on first system
Second linux install is destroyed by Selinux change on first system
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2007-06-08 14:48 EDT by Leslie Satenstein
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-11 09:33:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Leslie Satenstein 2007-06-08 14:48:54 EDT
Description of problem:

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

How reproducible:

Steps to Reproduce:
1. I have two systems on two separate hard disks. Each is a fedora system.
2. Disk 1 is fc7 32 bit
3. Disk 2 is fc7 64 bit
I had trouble with yum that would not use a freshrpms repro.
I changed Selinux to permissive, and did the scan on system 1

Actual results:

System 1 was unaffected, but since the / file system from system 2  was mounted
via fstab could  not be logged into, it appears that X windows on the system 2
got corrupted, and X windows complained about an error preventing a logon, even
as root.

Expected results:

Did not expect 2nd system to block logons.

Additional info:
The first system (32bit fc7)

/dev/main/root          /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/main/tmp           /tmp                    ext3    defaults        1 2
/dev/main/data          /data                   ext3    defaults        1 2
/dev/main/swap          swap                    swap    defaults        0 0
/dev/main/home          /home                   ext3    defaults        1 2
####### this file is for install on the maxtor hda drive (200gig) #########
####### below is the fstab for the fc7 64 bit system              #########
/dev/MainSda/root       /sdaroot                ext3    defaults        1 1
LABEL=/boot1            /sdaboot                ext3    defaults        1 2
/dev/MainSda/data       /sdadata                ext3    defaults        1 2
/dev/MainSda/home       /sdahome                ext3    defaults        1 2
/dev/MainSda/tmp        /sdatmp                 ext3    defaults        1 2

What I eventually did, is reinstall the second system.
Comment 1 Daniel Walsh 2007-06-11 09:33:42 EDT
This sounds like you relabeled one system while the other was mounted, thus
destroying the second file systems labeling.

A relabel will cause all file systems currently mounted to be labeled according
the OS that is doing the labeling.    You could have rebooted the second system
in permissive mode and caused it to do a relabel.  

In order to relabel you need to either unmount the alternate systems shares
before relabeling or mount the secondary shares file system with a context mount

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