Bug 732505 - change/regression in mount(8) usage of MS_BIND
Summary: change/regression in mount(8) usage of MS_BIND
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-22 17:59 UTC by Eric Paris
Modified: 2012-02-21 17:03 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-21 17:03:47 UTC


Attachments (Terms of Use)

Description Eric Paris 2011-08-22 17:59:30 UTC
When setting up a chroot the selinux community will sometimes use the following set of steps.

mount --bind /selinux /var/chroot/selinux
mount -o remount,ro /var/chroot/selinux

Under F14 util-linux-ng-2.18-4.8.fc14.x86_64 the remount command results in:

mount("/selinux", "/var/chroot/selinux", 0x7ff5f154ea69, MS_MGC_VAL|MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = 0

Which clearly includes MS_BIND

Under F15 util-linux-2.19.1-1.4.fc15.x86_64 the remount command results in:

mount("selinuxfs", "/var/chroot/selinux", 0x7ffc9dd917b0, MS_REMOUNT|MS_RELATIME, NULL) = 0

Which does NOT include the MS_BIND option.

This means that in F14 we got /selinux RW and /var/chroot/selinux RO but in F15 BOTH /selinux and /var/chroot/selinux are RO.

I can work around this by using the command:
mount -o remount,ro,bind /var/chroot/selinux in F15, but mount broke code that was already working and I don't understand why.....

Comment 1 Eric Paris 2011-08-22 18:54:27 UTC
apparently this is a result of the switch from mtab to /proc/mounts so mount doesn't know it is a bind....  dooh

Comment 2 Karel Zak 2011-08-22 21:32:00 UTC
Yes, this is known issue which is documented in the mount man page.

Maybe we need something like  

   mount --ro-bind /mountpoint

to provide more user-friendly command line interface for the crazy MS_RDONLY|MS_REMOUNT|MS_BIND semantic.

Comment 3 Karel Zak 2011-10-20 10:47:07 UTC
Note that I have added this to the upstream TODO file. We need this for all propagation flags (MS_SHARE, MS_PRIVATE, ...).


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