Bug 833871

Summary:	Disk mounted via nautilus got all labels screwed up.
Product:	[Fedora] Fedora	Reporter:	Simo Sorce <ssorce>
Component:	policycoreutils	Assignee:	Daniel Walsh <dwalsh>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	17	CC:	davidz, dwalsh, mgrepl
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-12-20 15:17:26 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Simo Sorce 2012-06-20 13:53:32 UTC

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 17:27:08 UTC

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 19:02:44 UTC

Fixed in selinux-policy-3.10.0-133.fc17

Comment 3 Daniel Walsh 2012-06-20 19:03:31 UTC

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 19:12:12 UTC

What happens if I mount at disk at /Stuff (via /etc/fstab). Will that get relabeled too?

Comment 5 Daniel Walsh 2012-06-20 20:02:52 UTC

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 13:04:30 UTC

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 23:56:25 UTC

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-11-01 01:25:13 UTC

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 15:17:28 UTC

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.