RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1209594 - RHEL7: unshare: add --propagation, use MS_PRIVATE by default
Summary: RHEL7: unshare: add --propagation, use MS_PRIVATE by default
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: util-linux
Version: 7.2
Hardware: Unspecified
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Karel Zak
QA Contact: Tomas Dolezal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-07 17:41 UTC by Wesley Duffee-Braun
Modified: 2015-11-19 12:19 UTC (History)
3 users (show)

Fixed In Version: util-linux-2.23.2-23.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 12:19:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2093 0 normal SHIPPED_LIVE util-linux bug fix and enhancement update 2015-11-19 10:51:15 UTC

Description Wesley Duffee-Braun 2015-04-07 17:41:49 UTC
Description of problem:
In RHEL 7, it appears that 'unshare -m' does not provide a separate mounts namespace. This is different from the RHEL 6 behavior, which works as expected. 

Version-Release number of selected component (if applicable):
util-linux-2.23.2-21.el7.x86_64
kernel-3.10.0-229.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Open a terminal to a RHEL 7 system and mount a filesystem
2. Open another terminal on the system, execute 'unshare -m /bin/bash'
3. In the new bash shell, umount the filesytem

Actual results:
The filesystem is completely unmounted.

Expected results:
The filesystem should remain mounted to the terminal from Step 1 and should be unmounted in the bash shell that was called with unshared mount namespace.

Additional info:
This works in RHEL 6 (kernel 2.6.32-504.12.2.el6.x86_64, util-linux-ng-2.17.2-12.18.el6.x86_64). Below are examples of the behavior in RHEL 6 contrasted with 7.

RHEL 6 (Expected Behavior):

RHEL 6 Shell 1: 
# mount /dev/sda1 /mnt/sda1/
# cat /proc/mounts | grep sda
/dev/sda1 /mnt/sda1 ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
#

RHEL 6 Shell 2:
# cat /proc/mounts | grep sda
/dev/sda1 /mnt/sda1 ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
# unshare -m /bin/bash
# umount /mnt/sda1
# cat /proc/mounts | grep sda
#

and now back to RHEL 6 Shell 1:
# cat /proc/mounts | grep sda
/dev/sda1 /mnt/sda1 ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0

RHEL 7 (Unexpected Behavior):

RHEL 7 Shell 1:
# mount /dev/sda1 /mnt/sda1
# cat /proc/mounts | grep sda
/dev/sda1 /mnt/sda1 ext4 rw,seclabel,relatime,data=ordered 0 0
#

RHEL 7 Shell 2:
# cat /proc/mounts | grep sda
/dev/sda1 /mnt/sda1 ext4 rw,seclabel,relatime,data=ordered 0 0
# unshare -m /bin/bash
# umount /mnt/sda1/
# cat /proc/mounts | grep sda
#

and now back to RHEL 7 Shell 1:
# cat /proc/mounts | grep sda
#

This is the difference - in 7 for all shells, once the umount is made inside the unshared bash environment, the mount is gone. In 6 it remains.

Comment 2 Karel Zak 2015-04-08 00:05:12 UTC
man unshare:

Mounting and unmounting filesystems will not affect the rest  of  the  system  (CLONE_NEWNS flag),  except  for  filesystems  which are explicitly marked as shared (with mount --make-shared; see /proc/self/mountinfo for the shared flags).

It's recommended to use mount --make-rprivate or mount --make-rslave after unshare  --mount to make sure that mountpoints in the new namespace are really unshared from parental names‐pace.


... on RHEL-7 (due to systemd) the default is "shared" flag. The current unshare(1) behaviour is normal.

In upstream tree we have a patch (f0f22e9c6f109f8c1234caa3173368ef43b023eb) to explicitly mark the mount tree in a new namespace as "private" to hide the difference between distributions. Maybe we can backport this to RHEL7.

Comment 3 Wesley Duffee-Braun 2015-04-08 17:18:55 UTC
Hello Karel,

Thank you for your message. However, I'm not seeing the behavior work as described in your comment. When I run mount --make-rprivate /mnt/sda1 (for example) after the unshare -m I do see the shared flag disappear from /proc/self/mountinfo. However, when I do the unmount in the unshare -m environment, I still see the entire filesystem unmount for all environments. 

Shell 1:

# mount /dev/sda1 /mnt/sda1/
# mount --make-rprivate /mnt/sda1/
# grep sda1 /proc/self/mountinfo 
44 37 8:1 / /mnt/sda1 rw,relatime - ext4 /dev/sda1 rw,seclabel,data=ordered

 - so no shared flag in the entry

Shell 2:

# unshare -m
# grep sda1 /proc/self/mountinfo 
73 46 8:1 / /mnt/sda1 rw,relatime - ext4 /dev/sda1 rw,seclabel,data=ordered
# umount /mnt/sda1
# grep sda1 /proc/mounts
#

Back to Shell 1:

# grep sda1 /proc/mounts
#

Please let me know if this is expected? Perhaps I'm doing something wrong, but I'm still not seeing the namespaces be separated.

Thanks!

Comment 4 Karel Zak 2015-04-09 11:51:29 UTC
Well, I thought something else:

# mount /dev/sdc1 /mnt/test

# unshare --mount
# mount --make-rprivate /
# umount /mnt/test

Now within unshared shell it's umounted, but rest of the system see the device still mounted.

Note that --make-rprivate is executed within the namespace!

The current upstream unshare(1) version calls --make-rprivate automatically, so it's possible to skip this extra step.

---

Just for the record -- if you want to rewrite your example and call --make-rprivate outside the namespace than you have to do:

Shell 1:

# mount --bind /mnt/test /mnt/test
# mount --make-rprivate /mnt/test
# mount /dev/sdc1 /mnt/test

Shell 2:
# unshare --mount
# umount /mnt/test
# findmnt /dev/sdc1; echo $?
1

... not mounted within the namespace

back to Shell 1:
# findmnt /dev/sdc1
TARGET    SOURCE    FSTYPE OPTIONS
/mnt/test /dev/sdc1 ext4   rw,relatime,seclabel,stripe=32,data=ordered

... still mounted :-)

In this case you create "private" subtree /mnt/test and mount the device into the tree (the propagation is controlled by parent, not by the filesystem). Anyway I guess this is too complicated and mostly academical, IMHO my previous example is more usable.

Comment 5 Wesley Duffee-Braun 2015-04-09 14:01:28 UTC
(In reply to Karel Zak from comment #4)

Thanks Karel,

With your example 1 above the unshared mounts namespace works as I expected. I appreciate the clarity.

Thanks,
Wesley

> Well, I thought something else:
> 
> # mount /dev/sdc1 /mnt/test
> 
> # unshare --mount
> # mount --make-rprivate /
> # umount /mnt/test
> 
> Now within unshared shell it's umounted, but rest of the system see the
> device still mounted.
> 
> Note that --make-rprivate is executed within the namespace!
> 
> The current upstream unshare(1) version calls --make-rprivate automatically,
> so it's possible to skip this extra step.
> 
> ---
> 
> Just for the record -- if you want to rewrite your example and call
> --make-rprivate outside the namespace than you have to do:
> 
> Shell 1:
> 
> # mount --bind /mnt/test /mnt/test
> # mount --make-rprivate /mnt/test
> # mount /dev/sdc1 /mnt/test
> 
> Shell 2:
> # unshare --mount
> # umount /mnt/test
> # findmnt /dev/sdc1; echo $?
> 1
> 
> ... not mounted within the namespace
> 
> back to Shell 1:
> # findmnt /dev/sdc1
> TARGET    SOURCE    FSTYPE OPTIONS
> /mnt/test /dev/sdc1 ext4   rw,relatime,seclabel,stripe=32,data=ordered
> 
> ... still mounted :-)
> 
> In this case you create "private" subtree /mnt/test and mount the device
> into the tree (the propagation is controlled by parent, not by the
> filesystem). Anyway I guess this is too complicated and mostly academical,
> IMHO my previous example is more usable.

Comment 11 errata-xmlrpc 2015-11-19 12:19:52 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2093.html


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