# mount_namespaces

## NAME



           mount_namespaces - overview of Linux mount namespaces
    


## DESCRIPTION



           For an overview of namespaces, see namespaces(7).
    
           Mount namespaces provide isolation of the list of mounts seen by
           the processes in each namespace instance.  Thus, the processes in
           each of the mount namespace instances will see distinct single-
           directory hierarchies.
    
           The views provided by the _/proc/_ pid _/mounts_ , _/proc/_ pid _/mountinfo_ ,
           and _/proc/_ pid _/mountstats_ files (all described in proc(5))
           correspond to the mount namespace in which the process with the
           PID _pid_ resides.  (All of the processes that reside in the same
           mount namespace will see the same view in these files.)
    
           A new mount namespace is created using either clone(2) or
           unshare(2) with the **CLONE_NEWNS** flag.  When a new mount namespace
           is created, its mount list is initialized as follows:
    
           •  If the namespace is created using clone(2), the mount list of
              the child's namespace is a copy of the mount list in the parent
              process's mount namespace.
    
           •  If the namespace is created using unshare(2), the mount list of
              the new namespace is a copy of the mount list in the caller's
              previous mount namespace.
    
           Subsequent modifications to the mount list (mount(2) and
           umount(2)) in either mount namespace will not (by default) affect
           the mount list seen in the other namespace (but see the following
           discussion of shared subtrees).
    


## SHARED SUBTREES



           After the implementation of mount namespaces was completed,
           experience showed that the isolation that they provided was, in
           some cases, too great.  For example, in order to make a newly
           loaded optical disk available in all mount namespaces, a mount
           operation was required in each namespace.  For this use case, and
           others, the shared subtree feature was introduced in Linux 2.6.15.
           This feature allows for automatic, controlled propagation of
           mount(2) and umount(2) _events_ between namespaces (or, more
           precisely, between the mounts that are members of a _peer group_
           that are propagating events to one another).
    
           Each mount is marked (via mount(2)) as having one of the following
           _propagation types_ :
    
           **MS_SHARED**
                  This mount shares events with members of a peer group.
                  mount(2) and umount(2) events immediately under this mount
                  will propagate to the other mounts that are members of the
                  peer group.  _Propagation_ here means that the same mount(2)
                  or umount(2) will automatically occur under all of the
                  other mounts in the peer group.  Conversely, mount(2) and
                  umount(2) events that take place under peer mounts will
                  propagate to this mount.
    
           **MS_PRIVATE**
                  This mount is private; it does not have a peer group.
                  mount(2) and umount(2) events do not propagate into or out
                  of this mount.
    
           **MS_SLAVE**
                  mount(2) and umount(2) events propagate into this mount
                  from a (master) shared peer group.  mount(2) and umount(2)
                  events under this mount do not propagate to any peer.
    
                  Note that a mount can be the slave of another peer group
                  while at the same time sharing mount(2) and umount(2)
                  events with a peer group of which it is a member.  (More
                  precisely, one peer group can be the slave of another peer
                  group.)
    
           **MS_UNBINDABLE**
                  This is like a private mount, and in addition this mount
                  can't be bind mounted.  Attempts to bind mount this mount
                  (mount(2) with the **MS_BIND** flag) will fail.
    
                  When a recursive bind mount (mount(2) with the **MS_BIND** and
                  **MS_REC** flags) is performed on a directory subtree, any bind
                  mounts within the subtree are automatically pruned (i.e.,
                  not replicated) when replicating that subtree to produce
                  the target subtree.
    
           For a discussion of the propagation type assigned to a new mount,
           see NOTES.
    
           The propagation type is a per-mount-point setting; some mounts may
           be marked as shared (with each shared mount being a member of a
           distinct peer group), while others are private (or slaved or
           unbindable).
    
           Note that a mount's propagation type determines whether mount(2)
           and umount(2) of mounts _immediately under_ the mount are
           propagated.  Thus, the propagation type does not affect
           propagation of events for grandchildren and further removed
           descendant mounts.  What happens if the mount itself is unmounted
           is determined by the propagation type that is in effect for the
           _parent_ of the mount.
    
           Members are added to a _peer group_ when a mount is marked as shared
           and either:
    
           (a)  the mount is replicated during the creation of a new mount
                namespace; or
    
           (b)  a new bind mount is created from the mount.
    
           In both of these cases, the new mount joins the peer group of
           which the existing mount is a member.
    
           A new peer group is also created when a child mount is created
           under an existing mount that is marked as shared.  In this case,
           the new child mount is also marked as shared and the resulting
           peer group consists of all the mounts that are replicated under
           the peers of parent mounts.
    
           A mount ceases to be a member of a peer group when either the
           mount is explicitly unmounted, or when the mount is implicitly
           unmounted because a mount namespace is removed (because it has no
           more member processes).
    
           The propagation type of the mounts in a mount namespace can be
           discovered via the "optional fields" exposed in
           _/proc/_ pid _/mountinfo_.  (See proc(5) for details of this file.)  The
           following tags can appear in the optional fields for a record in
           that file:
    
           _shared:X_
                  This mount is shared in peer group _X_.  Each peer group has
                  a unique ID that is automatically generated by the kernel,
                  and all mounts in the same peer group will show the same
                  ID.  (These IDs are assigned starting from the value 1, and
                  may be recycled when a peer group ceases to have any
                  members.)
    
           _master:X_
                  This mount is a slave to shared peer group _X_.
    
           _propagate_from:X_ (since Linux 2.6.26)
                  This mount is a slave and receives propagation from shared
                  peer group _X_.  This tag will always appear in conjunction
                  with a _master:X_ tag.  Here, _X_ is the closest dominant peer
                  group under the process's root directory.  If _X_ is the
                  immediate master of the mount, or if there is no dominant
                  peer group under the same root, then only the _master:X_
                  field is present and not the _propagate_from:X_ field.  For
                  further details, see below.
    
           _unbindable_
                  This is an unbindable mount.
    
           If none of the above tags is present, then this is a private
           mount.
    
       **MS_SHARED and MS_PRIVATE example**
           Suppose that on a terminal in the initial mount namespace, we mark
           one mount as shared and another as private, and then view the
           mounts in _/proc/self/mountinfo_ :
    
               sh1# **mount --make-shared /mntS**
               sh1# **mount --make-private /mntP**
               sh1# **cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'**
               77 61 8:17 / /mntS rw,relatime shared:1
               83 61 8:15 / /mntP rw,relatime
    
           From the _/proc/self/mountinfo_ output, we see that _/mntS_ is a
           shared mount in peer group 1, and that _/mntP_ has no optional tags,
           indicating that it is a private mount.  The first two fields in
           each record in this file are the unique ID for this mount, and the
           mount ID of the parent mount.  We can further inspect this file to
           see that the parent mount of _/mntS_ and _/mntP_ is the root
           directory, _/_ , which is mounted as private:
    
               sh1# **cat /proc/self/mountinfo | awk '$1 == 61' | sed 's/ - .*//'**
               61 0 8:2 / / rw,relatime
    
           On a second terminal, we create a new mount namespace where we run
           a second shell and inspect the mounts:
    
               $ **PS1='sh2# ' sudo unshare -m --propagation unchanged sh**
               sh2# **cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'**
               222 145 8:17 / /mntS rw,relatime shared:1
               225 145 8:15 / /mntP rw,relatime
    
           The new mount namespace received a copy of the initial mount
           namespace's mounts.  These new mounts maintain the same
           propagation types, but have unique mount IDs.  (The
           _--propagation unchanged_ option prevents unshare(1) from marking
           all mounts as private when creating a new mount namespace, which
           it does by default.)
    
           In the second terminal, we then create submounts under each of
           _/mntS_ and _/mntP_ and inspect the set-up:
    
               sh2# **mkdir /mntS/a**
               sh2# **mount /dev/sdb6 /mntS/a**
               sh2# **mkdir /mntP/b**
               sh2# **mount /dev/sdb7 /mntP/b**
               sh2# **cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'**
               222 145 8:17 / /mntS rw,relatime shared:1
               225 145 8:15 / /mntP rw,relatime
               178 222 8:22 / /mntS/a rw,relatime shared:2
               230 225 8:23 / /mntP/b rw,relatime
    
           From the above, it can be seen that _/mntS/a_ was created as shared
           (inheriting this setting from its parent mount) and _/mntP/b_ was
           created as a private mount.
    
           Returning to the first terminal and inspecting the set-up, we see
           that the new mount created under the shared mount _/mntS_ propagated
           to its peer mount (in the initial mount namespace), but the new
           mount created under the private mount _/mntP_ did not propagate:
    
               sh1# **cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'**
               77 61 8:17 / /mntS rw,relatime shared:1
               83 61 8:15 / /mntP rw,relatime
               179 77 8:22 / /mntS/a rw,relatime shared:2
    
       **MS_SLAVE example**
           Making a mount a slave allows it to receive propagated mount(2)
           and umount(2) events from a master shared peer group, while
           preventing it from propagating events to that master.  This is
           useful if we want to (say) receive a mount event when an optical
           disk is mounted in the master shared peer group (in another mount
           namespace), but want to prevent mount(2) and umount(2) events
           under the slave mount from having side effects in other
           namespaces.
    
           We can demonstrate the effect of slaving by first marking two
           mounts as shared in the initial mount namespace:
    
               sh1# **mount --make-shared /mntX**
               sh1# **mount --make-shared /mntY**
               sh1# **cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'**
               132 83 8:23 / /mntX rw,relatime shared:1
               133 83 8:22 / /mntY rw,relatime shared:2
    
           On a second terminal, we create a new mount namespace and inspect
           the mounts:
    
               sh2# **unshare -m --propagation unchanged sh**
               sh2# **cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'**
               168 167 8:23 / /mntX rw,relatime shared:1
               169 167 8:22 / /mntY rw,relatime shared:2
    
           In the new mount namespace, we then mark one of the mounts as a
           slave:
    
               sh2# **mount --make-slave /mntY**
               sh2# **cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'**
               168 167 8:23 / /mntX rw,relatime shared:1
               169 167 8:22 / /mntY rw,relatime master:2
    
           From the above output, we see that _/mntY_ is now a slave mount that
           is receiving propagation events from the shared peer group with
           the ID 2.
    
           Continuing in the new namespace, we create submounts under each of
           _/mntX_ and _/mntY_ :
    
               sh2# **mkdir /mntX/a**
               sh2# **mount /dev/sda3 /mntX/a**
               sh2# **mkdir /mntY/b**
               sh2# **mount /dev/sda5 /mntY/b**
    
           When we inspect the state of the mounts in the new mount
           namespace, we see that _/mntX/a_ was created as a new shared mount
           (inheriting the "shared" setting from its parent mount) and
           _/mntY/b_ was created as a private mount:
    
               sh2# **cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'**
               168 167 8:23 / /mntX rw,relatime shared:1
               169 167 8:22 / /mntY rw,relatime master:2
               173 168 8:3 / /mntX/a rw,relatime shared:3
               175 169 8:5 / /mntY/b rw,relatime
    
           Returning to the first terminal (in the initial mount namespace),
           we see that the mount _/mntX/a_ propagated to the peer (the shared
           _/mntX_), but the mount _/mntY/b_ was not propagated:
    
               sh1# **cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'**
               132 83 8:23 / /mntX rw,relatime shared:1
               133 83 8:22 / /mntY rw,relatime shared:2
               174 132 8:3 / /mntX/a rw,relatime shared:3
    
           Now we create a new mount under _/mntY_ in the first shell:
    
               sh1# **mkdir /mntY/c**
               sh1# **mount /dev/sda1 /mntY/c**
               sh1# **cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'**
               132 83 8:23 / /mntX rw,relatime shared:1
               133 83 8:22 / /mntY rw,relatime shared:2
               174 132 8:3 / /mntX/a rw,relatime shared:3
               178 133 8:1 / /mntY/c rw,relatime shared:4
    
           When we examine the mounts in the second mount namespace, we see
           that in this case the new mount has been propagated to the slave
           mount, and that the new mount is itself a slave mount (to peer
           group 4):
    
               sh2# **cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'**
               168 167 8:23 / /mntX rw,relatime shared:1
               169 167 8:22 / /mntY rw,relatime master:2
               173 168 8:3 / /mntX/a rw,relatime shared:3
               175 169 8:5 / /mntY/b rw,relatime
               179 169 8:1 / /mntY/c rw,relatime master:4
    
       **MS_UNBINDABLE example**
           One of the primary purposes of unbindable mounts is to avoid the
           "mount explosion" problem when repeatedly performing bind mounts
           of a higher-level subtree at a lower-level mount.  The problem is
           illustrated by the following shell session.
    
           Suppose we have a system with the following mounts:
    
               # **mount | awk '{print $1, $2, $3}'**
               /dev/sda1 on /
               /dev/sdb6 on /mntX
               /dev/sdb7 on /mntY
    
           Suppose furthermore that we wish to recursively bind mount the
           root directory under several users' home directories.  We do this
           for the first user, and inspect the mounts:
    
               # **mount --rbind / /home/cecilia/**
               # **mount | awk '{print $1, $2, $3}'**
               /dev/sda1 on /
               /dev/sdb6 on /mntX
               /dev/sdb7 on /mntY
               /dev/sda1 on /home/cecilia
               /dev/sdb6 on /home/cecilia/mntX
               /dev/sdb7 on /home/cecilia/mntY
    
           When we repeat this operation for the second user, we start to see
           the explosion problem:
    
               # **mount --rbind / /home/henry**
               # **mount | awk '{print $1, $2, $3}'**
               /dev/sda1 on /
               /dev/sdb6 on /mntX
               /dev/sdb7 on /mntY
               /dev/sda1 on /home/cecilia
               /dev/sdb6 on /home/cecilia/mntX
               /dev/sdb7 on /home/cecilia/mntY
               /dev/sda1 on /home/henry
               /dev/sdb6 on /home/henry/mntX
               /dev/sdb7 on /home/henry/mntY
               /dev/sda1 on /home/henry/home/cecilia
               /dev/sdb6 on /home/henry/home/cecilia/mntX
               /dev/sdb7 on /home/henry/home/cecilia/mntY
    
           Under _/home/henry_ , we have not only recursively added the _/mntX_
           and _/mntY_ mounts, but also the recursive mounts of those
           directories under _/home/cecilia_ that were created in the previous
           step.  Upon repeating the step for a third user, it becomes
           obvious that the explosion is exponential in nature:
    
               # **mount --rbind / /home/otto**
               # **mount | awk '{print $1, $2, $3}'**
               /dev/sda1 on /
               /dev/sdb6 on /mntX
               /dev/sdb7 on /mntY
               /dev/sda1 on /home/cecilia
               /dev/sdb6 on /home/cecilia/mntX
               /dev/sdb7 on /home/cecilia/mntY
               /dev/sda1 on /home/henry
               /dev/sdb6 on /home/henry/mntX
               /dev/sdb7 on /home/henry/mntY
               /dev/sda1 on /home/henry/home/cecilia
               /dev/sdb6 on /home/henry/home/cecilia/mntX
               /dev/sdb7 on /home/henry/home/cecilia/mntY
               /dev/sda1 on /home/otto
               /dev/sdb6 on /home/otto/mntX
               /dev/sdb7 on /home/otto/mntY
               /dev/sda1 on /home/otto/home/cecilia
               /dev/sdb6 on /home/otto/home/cecilia/mntX
               /dev/sdb7 on /home/otto/home/cecilia/mntY
               /dev/sda1 on /home/otto/home/henry
               /dev/sdb6 on /home/otto/home/henry/mntX
               /dev/sdb7 on /home/otto/home/henry/mntY
               /dev/sda1 on /home/otto/home/henry/home/cecilia
               /dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
               /dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY
    
           The mount explosion problem in the above scenario can be avoided
           by making each of the new mounts unbindable.  The effect of doing
           this is that recursive mounts of the root directory will not
           replicate the unbindable mounts.  We make such a mount for the
           first user:
    
               # **mount --rbind --make-unbindable / /home/cecilia**
    
           Before going further, we show that unbindable mounts are indeed
           unbindable:
    
               # **mkdir /mntZ**
               # **mount --bind /home/cecilia /mntZ**
               mount: wrong fs type, bad option, bad superblock on /home/cecilia,
                      missing codepage or helper program, or other error
    
                      In some cases useful info is found in syslog - try
                      dmesg | tail or so.
    
           Now we create unbindable recursive bind mounts for the other two
           users:
    
               # **mount --rbind --make-unbindable / /home/henry**
               # **mount --rbind --make-unbindable / /home/otto**
    
           Upon examining the list of mounts, we see there has been no
           explosion of mounts, because the unbindable mounts were not
           replicated under each user's directory:
    
               # **mount | awk '{print $1, $2, $3}'**
               /dev/sda1 on /
               /dev/sdb6 on /mntX
               /dev/sdb7 on /mntY
               /dev/sda1 on /home/cecilia
               /dev/sdb6 on /home/cecilia/mntX
               /dev/sdb7 on /home/cecilia/mntY
               /dev/sda1 on /home/henry
               /dev/sdb6 on /home/henry/mntX
               /dev/sdb7 on /home/henry/mntY
               /dev/sda1 on /home/otto
               /dev/sdb6 on /home/otto/mntX
               /dev/sdb7 on /home/otto/mntY
    
       **Propagation type transitions**
           The following table shows the effect that applying a new
           propagation type (i.e., _mount --make-xxxx_) has on the existing
           propagation type of a mount.  The rows correspond to existing
           propagation types, and the columns are the new propagation
           settings.  For reasons of space, "private" is abbreviated as
           "priv" and "unbindable" as "unbind".
                         **make-shared   make-slave      make-priv  make-unbind**
           ─────────────┬───────────────────────────────────────────────────────
           **shared** │shared        slave/priv [1]  priv       unbind
           **slave** │slave+shared  slave [2]       priv       unbind
           **slave+shared** │slave+shared  slave           priv       unbind
           **private** │shared        priv [2]        priv       unbind
           **unbindable** │shared        unbind [2]      priv       unbind
    
           Note the following details to the table:
    
           [1]  If a shared mount is the only mount in its peer group, making
                it a slave automatically makes it private.
    
           [2]  Slaving a nonshared mount has no effect on the mount.
    
       **Bind (MS_BIND) semantics**
           Suppose that the following command is performed:
    
               mount --bind A/a B/b
    
           Here, _A_ is the source mount, _B_ is the destination mount, _a_ is a
           subdirectory path under the mount point _A_ , and _b_ is a subdirectory
           path under the mount point _B_.  The propagation type of the
           resulting mount, _B/b_ , depends on the propagation types of the
           mounts _A_ and _B_ , and is summarized in the following table.
    
                                      **source(A)**
                              **shared  private    slave         unbind**
           ──────────────────┬──────────────────────────────────────────
           **dest(B)  shared** │shared  shared     slave+shared  invalid
                    **nonshared** │shared  private    slave         invalid
    
           Note that a recursive bind of a subtree follows the same semantics
           as for a bind operation on each mount in the subtree.  (Unbindable
           mounts are automatically pruned at the target mount point.)
    
           For further details, see
           _Documentation/filesystems/sharedsubtree.rst_ in the kernel source
           tree.
    
       **Move (MS_MOVE) semantics**
           Suppose that the following command is performed:
    
               mount --move A B/b
    
           Here, _A_ is the source mount, _B_ is the destination mount, and _b_ is
           a subdirectory path under the mount point _B_.  The propagation type
           of the resulting mount, _B/b_ , depends on the propagation types of
           the mounts _A_ and _B_ , and is summarized in the following table.
    
                                      **source(A)**
                              **shared  private    slave         unbind**
           ──────────────────┬─────────────────────────────────────────────
           **dest(B)  shared** │shared  shared     slave+shared  invalid
                    **nonshared** │shared  private    slave         unbindable
    
           Note: moving a mount that resides under a shared mount is invalid.
    
           For further details, see
           _Documentation/filesystems/sharedsubtree.rst_ in the kernel source
           tree.
    
       **Mount semantics**
           Suppose that we use the following command to create a mount:
    
               mount device B/b
    
           Here, _B_ is the destination mount, and _b_ is a subdirectory path
           under the mount point _B_.  The propagation type of the resulting
           mount, _B/b_ , follows the same rules as for a bind mount, where the
           propagation type of the source mount is considered always to be
           private.
    
       **Unmount semantics**
           Suppose that we use the following command to tear down a mount:
    
               umount A
    
           Here, _A_ is a mount on _B/b_ , where _B_ is the parent mount and _b_ is a
           subdirectory path under the mount point _B_.  If **B** is shared, then
           all most-recently-mounted mounts at _b_ on mounts that receive
           propagation from mount _B_ and do not have submounts under them are
           unmounted.
    
       **The /proc/ pid /mountinfo propagate_from tag**
           The _propagate_from:X_ tag is shown in the optional fields of a
           _/proc/_ pid _/mountinfo_ record in cases where a process can't see a
           slave's immediate master (i.e., the pathname of the master is not
           reachable from the filesystem root directory) and so cannot
           determine the chain of propagation between the mounts it can see.
    
           In the following example, we first create a two-link master-slave
           chain between the mounts _/mnt_ , _/tmp/etc_ , and _/mnt/tmp/etc_.  Then
           the chroot(1) command is used to make the _/tmp/etc_ mount point
           unreachable from the root directory, creating a situation where
           the master of _/mnt/tmp/etc_ is not reachable from the (new) root
           directory of the process.
    
           First, we bind mount the root directory onto _/mnt_ and then bind
           mount _/proc_ at _/mnt/proc_ so that after the later chroot(1) the
           proc(5) filesystem remains visible at the correct location in the
           chroot-ed environment.
    
               # **mkdir -p /mnt/proc**
               # **mount --bind / /mnt**
               # **mount --bind /proc /mnt/proc**
    
           Next, we ensure that the _/mnt_ mount is a shared mount in a new
           peer group (with no peers):
    
               # **mount --make-private /mnt** # Isolate from any previous peer group
               # **mount --make-shared /mnt**
               # **cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'**
               239 61 8:2 / /mnt ... shared:102
               248 239 0:4 / /mnt/proc ... shared:5
    
           Next, we bind mount _/mnt/etc_ onto _/tmp/etc_ :
    
               # **mkdir -p /tmp/etc**
               # **mount --bind /mnt/etc /tmp/etc**
               # **cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'**
               239 61 8:2 / /mnt ... shared:102
               248 239 0:4 / /mnt/proc ... shared:5
               267 40 8:2 /etc /tmp/etc ... shared:102
    
           Initially, these two mounts are in the same peer group, but we
           then make the _/tmp/etc_ a slave of _/mnt/etc_ , and then make _/tmp/etc_
           shared as well, so that it can propagate events to the next slave
           in the chain:
    
               # **mount --make-slave /tmp/etc**
               # **mount --make-shared /tmp/etc**
               # **cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'**
               239 61 8:2 / /mnt ... shared:102
               248 239 0:4 / /mnt/proc ... shared:5
               267 40 8:2 /etc /tmp/etc ... shared:105 master:102
    
           Then we bind mount _/tmp/etc_ onto _/mnt/tmp/etc_.  Again, the two
           mounts are initially in the same peer group, but we then make
           _/mnt/tmp/etc_ a slave of _/tmp/etc_ :
    
               # **mkdir -p /mnt/tmp/etc**
               # **mount --bind /tmp/etc /mnt/tmp/etc**
               # **mount --make-slave /mnt/tmp/etc**
               # **cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'**
               239 61 8:2 / /mnt ... shared:102
               248 239 0:4 / /mnt/proc ... shared:5
               267 40 8:2 /etc /tmp/etc ... shared:105 master:102
               273 239 8:2 /etc /mnt/tmp/etc ... master:105
    
           From the above, we see that _/mnt_ is the master of the slave
           _/tmp/etc_ , which in turn is the master of the slave _/mnt/tmp/etc_.
    
           We then chroot(1) to the _/mnt_ directory, which renders the mount
           with ID 267 unreachable from the (new) root directory:
    
               # **chroot /mnt**
    
           When we examine the state of the mounts inside the chroot-ed
           environment, we see the following:
    
               # **cat /proc/self/mountinfo | sed 's/ - .*//'**
               239 61 8:2 / / ... shared:102
               248 239 0:4 / /proc ... shared:5
               273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102
    
           Above, we see that the mount with ID 273 is a slave whose master
           is the peer group 105.  The mount point for that master is
           unreachable, and so a _propagate_from_ tag is displayed, indicating
           that the closest dominant peer group (i.e., the nearest reachable
           mount in the slave chain) is the peer group with the ID 102
           (corresponding to the _/mnt_ mount point before the chroot(1) was
           performed).
    


## STANDARDS



           Linux.
    


## NOTES



           The propagation type assigned to a new mount depends on the
           propagation type of the parent mount.  If the mount has a parent
           (i.e., it is a non-root mount) and the propagation type of the
           parent is **MS_SHARED** , then the propagation type of the new mount is
           also **MS_SHARED**.  Otherwise, the propagation type of the new mount
           is **MS_PRIVATE**.
    
           Notwithstanding the fact that the default propagation type for new
           mount is in many cases **MS_PRIVATE** , **MS_SHARED** is typically more
           useful.  For this reason, systemd(1) automatically remounts all
           mounts as **MS_SHARED** on system startup.  Thus, on most modern
           systems, the default propagation type is in practice **MS_SHARED**.
    
           Since, when one uses unshare(1) to create a mount namespace, the
           goal is commonly to provide full isolation of the mounts in the
           new namespace, unshare(1) (since _util-linux_ 2.27) in turn reverses
           the step performed by systemd(1), by making all mounts private in
           the new namespace.  That is, unshare(1) performs the equivalent of
           the following in the new mount namespace:
    
               mount --make-rprivate /
    
           To prevent this, one can use the _--propagation unchanged_ option to
           unshare(1).
    
           An application that creates a new mount namespace directly using
           clone(2) or unshare(2) may desire to prevent propagation of mount
           events to other mount namespaces (as is done by unshare(1)).  This
           can be done by changing the propagation type of mounts in the new
           namespace to either **MS_SLAVE** or **MS_PRIVATE** , using a call such as
           the following:
    
               mount(NULL, "/", MS_SLAVE | MS_REC, NULL);
    
           For a discussion of propagation types when moving mounts (**MS_MOVE**)
           and creating bind mounts (**MS_BIND**), see
           _Documentation/filesystems/sharedsubtree.rst_.
    
       **Restrictions on mount namespaces**
           Note the following points with respect to mount namespaces:
    
           [1]  Each mount namespace has an owner user namespace.  As
                explained above, when a new mount namespace is created, its
                mount list is initialized as a copy of the mount list of
                another mount namespace.  If the new namespace and the
                namespace from which the mount list was copied are owned by
                different user namespaces, then the new mount namespace is
                considered _less privileged_.
    
           [2]  When creating a less privileged mount namespace, shared
                mounts are reduced to slave mounts.  This ensures that
                mappings performed in less privileged mount namespaces will
                not propagate to more privileged mount namespaces.
    
           [3]  Mounts that come as a single unit from a more privileged
                mount namespace are locked together and may not be separated
                in a less privileged mount namespace.  (The unshare(2)
                **CLONE_NEWNS** operation brings across all of the mounts from
                the original mount namespace as a single unit, and recursive
                mounts that propagate between mount namespaces propagate as a
                single unit.)
    
                In this context, "may not be separated" means that the mounts
                are locked so that they may not be individually unmounted.
                Consider the following example:
    
                    $ **sudo sh**
                    # **mount --bind /dev/null /etc/shadow**
                    # **cat /etc/shadow** # Produces no output
    
                The above steps, performed in a more privileged mount
                namespace, have created a bind mount that obscures the
                contents of the shadow password file, _/etc/shadow_.  For
                security reasons, it should not be possible to umount(2) that
                mount in a less privileged mount namespace, since that would
                reveal the contents of _/etc/shadow_.
    
                Suppose we now create a new mount namespace owned by a new
                user namespace.  The new mount namespace will inherit copies
                of all of the mounts from the previous mount namespace.
                However, those mounts will be locked because the new mount
                namespace is less privileged.  Consequently, an attempt to
                umount(2) the mount fails as show in the following step:
    
                    # **unshare --user --map-root-user --mount \**
                                   **strace -o /tmp/log \**
                                   **umount /etc/shadow**
                    umount: /etc/shadow: not mounted.
                    # **grep '^umount' /tmp/log**
                    umount2("/etc/shadow", 0)     = -1 EINVAL (Invalid argument)
    
                The error message from mount(8) is a little confusing, but
                the strace(1) output reveals that the underlying umount2(2)
                system call failed with the error **EINVAL** , which is the error
                that the kernel returns to indicate that the mount is locked.
    
                Note, however, that it is possible to stack (and unstack) a
                mount on top of one of the inherited locked mounts in a less
                privileged mount namespace:
    
                    # **echo 'aaaaa' > /tmp/a    **# File to mount onto /etc/shadow
                    # **unshare --user --map-root-user --mount \**
                        **sh -c 'mount --bind /tmp/a /etc/shadow; cat /etc/shadow'**
                    aaaaa
                    # **umount /etc/shadow**
    
                The final umount(8) command above, which is performed in the
                initial mount namespace, makes the original _/etc/shadow_ file
                once more visible in that namespace.
    
           [4]  Following on from point [3], note that it is possible to
                umount(2) an entire subtree of mounts that propagated as a
                unit into a less privileged mount namespace, as illustrated
                in the following example.
    
                First, we create new user and mount namespaces using
                unshare(1).  In the new mount namespace, the propagation type
                of all mounts is set to private.  We then create a shared
                bind mount at _/mnt_ , and a small hierarchy of mounts
                underneath that mount.
    
                    $ **PS1='ns1# ' sudo unshare --user --map-root-user \**
                                           **--mount --propagation private bash**
                    ns1# **echo $$** # We need the PID of this shell later
                    778501
                    ns1# **mount --make-shared --bind /mnt /mnt**
                    ns1# **mkdir /mnt/x**
                    ns1# **mount --make-private -t tmpfs none /mnt/x**
                    ns1# **mkdir /mnt/x/y**
                    ns1# **mount --make-private -t tmpfs none /mnt/x/y**
                    ns1# **grep /mnt /proc/self/mountinfo | sed 's/ - .*//'**
                    986 83 8:5 /mnt /mnt rw,relatime shared:344
                    989 986 0:56 / /mnt/x rw,relatime
                    990 989 0:57 / /mnt/x/y rw,relatime
    
                Continuing in the same shell session, we then create a second
                shell in a new user namespace and a new (less privileged)
                mount namespace and check the state of the propagated mounts
                rooted at _/mnt_.
    
                    ns1# **PS1='ns2# ' unshare --user --map-root-user \**
                                           **--mount --propagation unchanged bash**
                    ns2# **grep /mnt /proc/self/mountinfo | sed 's/ - .*//'**
                    1239 1204 8:5 /mnt /mnt rw,relatime master:344
                    1240 1239 0:56 / /mnt/x rw,relatime
                    1241 1240 0:57 / /mnt/x/y rw,relatime
    
                Of note in the above output is that the propagation type of
                the mount _/mnt_ has been reduced to slave, as explained in
                point [2].  This means that submount events will propagate
                from the master _/mnt_ in "ns1", but propagation will not occur
                in the opposite direction.
    
                From a separate terminal window, we then use nsenter(1) to
                enter the mount and user namespaces corresponding to "ns1".
                In that terminal window, we then recursively bind mount
                _/mnt/x_ at the location _/mnt/ppp_.
    
                    $ **PS1='ns3# ' sudo nsenter -t 778501 --user --mount**
                    ns3# **mount --rbind --make-private /mnt/x /mnt/ppp**
                    ns3# **grep /mnt /proc/self/mountinfo | sed 's/ - .*//'**
                    986 83 8:5 /mnt /mnt rw,relatime shared:344
                    989 986 0:56 / /mnt/x rw,relatime
                    990 989 0:57 / /mnt/x/y rw,relatime
                    1242 986 0:56 / /mnt/ppp rw,relatime
                    1243 1242 0:57 / /mnt/ppp/y rw,relatime shared:518
    
                Because the propagation type of the parent mount, _/mnt_ , was
                shared, the recursive bind mount propagated a small subtree
                of mounts under the slave mount _/mnt_ into "ns2", as can be
                verified by executing the following command in that shell
                session:
    
                    ns2# **grep /mnt /proc/self/mountinfo | sed 's/ - .*//'**
                    1239 1204 8:5 /mnt /mnt rw,relatime master:344
                    1240 1239 0:56 / /mnt/x rw,relatime
                    1241 1240 0:57 / /mnt/x/y rw,relatime
                    1244 1239 0:56 / /mnt/ppp rw,relatime
                    1245 1244 0:57 / /mnt/ppp/y rw,relatime master:518
    
                While it is not possible to umount(2) a part of the
                propagated subtree (_/mnt/ppp/y_) in "ns2", it is possible to
                umount(2) the entire subtree, as shown by the following
                commands:
    
                    ns2# **umount /mnt/ppp/y**
                    umount: /mnt/ppp/y: not mounted.
                    ns2# **umount -l /mnt/ppp | sed 's/ - .*//'** # Succeeds...
                    ns2# **grep /mnt /proc/self/mountinfo**
                    1239 1204 8:5 /mnt /mnt rw,relatime master:344
                    1240 1239 0:56 / /mnt/x rw,relatime
                    1241 1240 0:57 / /mnt/x/y rw,relatime
    
           [5]  The mount(2) flags **MS_RDONLY** , **MS_NOSUID** , **MS_NOEXEC** , and the
                "atime" flags (**MS_NOATIME** , **MS_NODIRATIME** , **MS_RELATIME**)
                settings become locked when propagated from a more privileged
                to a less privileged mount namespace, and may not be changed
                in the less privileged mount namespace.
    
                This point is illustrated in the following example where, in
                a more privileged mount namespace, we create a bind mount
                that is marked as read-only.  For security reasons, it should
                not be possible to make the mount writable in a less
                privileged mount namespace, and indeed the kernel prevents
                this:
    
                    $ **sudo mkdir /mnt/dir**
                    $ **sudo mount --bind -o ro /some/path /mnt/dir**
                    $ **sudo unshare --user --map-root-user --mount \**
                                   **mount -o remount,rw /mnt/dir**
                    mount: /mnt/dir: permission denied.
    
           [6]  A file or directory that is a mount point in one namespace
                that is not a mount point in another namespace, may be
                renamed, unlinked, or removed (rmdir(2)) in the mount
                namespace in which it is not a mount point (subject to the
                usual permission checks).  Consequently, the mount point is
                removed in the mount namespace where it was a mount point.
    
                Previously (before Linux 3.18), attempting to unlink, rename,
                or remove a file or directory that was a mount point in
                another mount namespace would result in the error **EBUSY**.
                That behavior had technical problems of enforcement (e.g.,
                for NFS) and permitted denial-of-service attacks against more
                privileged users (i.e., preventing individual files from
                being updated by bind mounting on top of them).
    


## EXAMPLES



           See pivot_root(2).
    


* * *