Bug 833871 - Disk mounted via nautilus got all labels screwed up.
Disk mounted via nautilus got all labels screwed up.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: policycoreutils (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-20 09:53 EDT by Simo Sorce
Modified: 2012-12-20 10:17 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-20 10:17:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Simo Sorce 2012-06-20 09:53:32 EDT
I am playing with a laptop for which I use 2 different root disks.
One is internal, and the other one is used via an USB adapter.
At boot time I F12 to choose the boot disk and boot the system I need.

Both disks have up to date Fedora 17 installed.

At one point I decided to boot from the usb drive and once logged in as user I asked nautilus to mount the root partition of the internal disk which was available for mount as I needed some of the files on that partition.
It was mounted in /run/media/...

Both systems use the same IPA user so after mount I can simply access the other disk home directory to fetch any file I need.

The problem is, after I did this all files on the internal disk root partition got relabeled to var_run_t.

Needless to say, the next time I booted from the internal disk I couldn't even login as root. I had to go in single user mode, no AVCs were logged.
After I finally discovered it was a lebeling issue a .autorelabel fixed most issues.

PROBLEM:
just mounting a disk should never cause a relabel.

EXPECTED OUTCOME:
I would expect that at worst the mount command passes options to ignore labels and mark the whole disk as file_t, but never relabel.
Comment 1 Simo Sorce 2012-06-20 13:27:08 EDT
Additional note.
This bug may have been triggered by a yum update that upgraded the selinux policy and relataed packages at the same time the disk was mounted.
So it may 'just' be an rpm upgrade bug, still shouldn't happen, as people may have automatic updates enabled and be working with mounted disks at the same time.
Looks like /run/media should be excluded from relabeling unless explicitly asked for by the admin.
Comment 2 Daniel Walsh 2012-06-20 15:02:44 EDT
Fixed in selinux-policy-3.10.0-133.fc17
Comment 3 Daniel Walsh 2012-06-20 15:03:31 EDT
We had proper labeling of /media but when it moved to /run/media we did not change the labels, With the label change it should block a relabel of content under /run/media.
Comment 4 David Zeuthen 2012-06-20 15:12:12 EDT
What happens if I mount at disk at /Stuff (via /etc/fstab). Will that get relabeled too?
Comment 5 Daniel Walsh 2012-06-20 16:02:52 EDT
If you mount a disk at a random location it and tell the system to fix labels it will change the labels.  We do keep /mnt, /media and /tmp from doing this.  /Stuff and its children would change to default_t.  

You can mount a directory with a context mount and this will  prevent this from happening.  A random directory in / is unlikely to get relabeled by the update process, but if you did a touch /.autorelabel or restorecon -R -v /

It will get relabeled.
Comment 6 Fedora Update System 2012-10-24 09:04:30 EDT
policycoreutils-2.1.12-4.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/policycoreutils-2.1.12-4.fc17
Comment 7 Fedora Update System 2012-10-24 19:56:25 EDT
Package policycoreutils-2.1.12-4.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing policycoreutils-2.1.12-4.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16848/policycoreutils-2.1.12-4.fc17
then log in and leave karma (feedback).
Comment 8 Fedora Update System 2012-10-31 21:25:13 EDT
Package policycoreutils-2.1.12-5.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing policycoreutils-2.1.12-5.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16848/policycoreutils-2.1.12-5.fc17
then log in and leave karma (feedback).
Comment 9 Fedora Update System 2012-12-20 10:17:28 EST
policycoreutils-2.1.12-5.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

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