GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


man:mount_namespaces

MOUNT_NAMESPACES(7) Linux Programmer's Manual MOUNT_NAMESPACES(7)

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 mount points 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.)
     When a  process  creates  a  new  mount  namespace  using  clone(2)  or
     unshare(2)  with the CLONE_NEWNS flag, the mount point list for the new
     namespace is a copy of the caller's mount point list.  Subsequent modi-
     fications  to  the  mount point list (mount(2) and umount(2)) in either
     mount namespace will not (by default) affect the mount point list  seen
     in the other namespace (but see the following discussion of shared sub-
     trees).
 Restrictions on mount namespaces
     Note the following points with respect to mount namespaces:
  • A mount namespace has an owner user namespace. A mount namespace

whose owner user namespace is different from the owner user names-

        pace of its parent mount namespace is considered a  less  privileged
        mount namespace.
  • When creating a less privileged mount namespace, shared mounts are

reduced to slave mounts. (Shared and slave mounts are discussed

        below.)   This  ensures  that  mappings performed in less privileged
        mount namespaces will not propagate to more privileged mount  names-
        paces.
  • Mounts that come as a single unit from more privileged mount 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 propa-
        gate as a single unit.)
  • 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.
  • 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).
        Previously, attempting to unlink, rename, or remove a file or direc-
        tory 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).

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 fea-
     ture  was  introduced  in  Linux 2.6.15.  This feature allows for auto-
     matic, controlled propagation  of  mount  and  unmount  events  between
     namespaces  (or,  more  precisely,  between the members of a peer group
     that are propagating events to one another).
     Each mount point is marked (via mount(2)) as having one of the  follow-
     ing propagation types:
     MS_SHARED
            This  mount  point  shares  events with members of a peer group.
            Mount and unmount events immediately under this mount point will
            propagate to the other mount points that are members of the peer
            group.  Propagation here means that the same  mount  or  unmount
            will  automatically occur under all of the other mount points in
            the peer group.  Conversely, mount and unmount events that  take
            place  under  peer  mount  points  will  propagate to this mount
            point.
     MS_PRIVATE
            This mount point is private; it does  not  have  a  peer  group.
            Mount  and  unmount  events do not propagate into or out of this
            mount point.
     MS_SLAVE
            Mount and unmount events propagate into this mount point from  a
            (master) shared peer group.  Mount and unmount events under this
            mount point do not propagate to any peer.
            Note that a mount point can be the slave of another  peer  group
            while  at  the same time sharing mount and unmount 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  mount  points
     may be marked as shared (with each shared mount point being a member of
     a distinct peer group), while others are private (or slaved or  unbind-
     able).
     Note  that  a  mount's  propagation  type determines whether mounts and
     unmounts of mount points immediately under the mount point  are  propa-
     gated.   Thus,  the  propagation  type  does  not affect propagation of
     events for grandchildren and further removed descendant  mount  points.
     What  happens  if  the mount point itself is unmounted is determined by
     the propagation type that is in effect for  the  parent  of  the  mount
     point.
     Members  are  added  to  a  peer  group when a mount point is marked as
     shared and either:
  • the mount point is replicated during the creation of a new mount

namespace; or

  • a new bind mount is created from the mount point.
     In  both  of  these  cases, the new mount point joins the peer group of
     which the existing mount point is a member.
     A new peer group is also created when a child mount  point  is  created
     under  an existing mount point that is marked as shared.  In this case,
     the new child mount point is also marked as shared  and  the  resulting
     peer  group  consists of all the mount points that are replicated under
     the peers of parent mount.
     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 mount points 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 point is shared in peer group X.  Each peer group has
            a  unique  ID that is automatically generated by the kernel, and
            all mount points 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 mas-
            ter: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 propa-
            gate_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  point 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  point  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  names-
     pace's mount points.  These new mount points maintain the same propaga-
     tion types, but have unique mount  IDs.   (The  --propagation unchanged
     option prevents unshare(1) from marking all mounts as private when cre-
     ating 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 point /mntS propagated  to
     its peer mount (in the initial mount namespace), but the new mount cre-
     ated under the private mount point /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 point a slave allows it to receive propagated mount  and
     unmount  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 mas-
     ter shared peer group (in another mount namespace), but want to prevent
     mount and unmount events under the slave mount from having side effects
     in other namespaces.
     We can demonstrate the effect of slaving by  first  marking  two  mount
     points 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
     mount points:
         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 mount points  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 mount points in the new mount names-
     pace, 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,rela-
         time 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,rela-
         time shared:2 174 132 8:3 / /mntX/a rw,relatime shared:3
     Now we create a new mount point 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 mount points in the second mount namespace, we see
     that in this case the new mount has been propagated to the slave  mount
     point,  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,rela-
         time 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 mas-
         ter:4
 MS_UNBINDABLE example
     One of the primary purposes of unbindable mounts is to avoid the "mount
     point  explosion"  problem  when repeatedly performing bind mounts of a
     higher-level subtree at a lower-level  mount  point.   The  problem  is
     illustrated by the following shell session.
     Suppose we have a system with the following mount points:
         #  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 mount points:
         # 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 unbind-
     able:
         #  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 mount points,  we  see  there  has  been  no
     explosion  of  mount  points,  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 point.  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 point, B is the destination mount point,  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 mount points 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.txt 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 point, B is the destination mount point,
     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 mount points 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.txt in
     the kernel source tree.
 Mount semantics
     Suppose that we use the following command to create a mount point:
         mount device B/b
     Here,  B  is  the destination mount point, 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 point:
         unmount A
     Here, A is a mount point 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  mount points 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 mount
     points 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 environ-
     ment, 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.

VERSIONS

     Mount namespaces first appeared in Linux 2.4.19.

CONFORMING TO

     Namespaces are a Linux-specific feature.

NOTES

     The propagation type assigned to a new mount point depends on the prop-
     agation type of the parent directory.  If the mount point has a  parent
     (i.e.,  it  is  a non-root mount point) 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_PRI-
     VATE.  But see also NOTES.
     Notwithstanding the fact that the  default  propagation  type  for  new
     mount  points  is in many cases MS_PRIVATE, MS_SHARED is typically more
     useful.  For this reason, systemd(1) automatically remounts  all  mount
     points  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 mount points in the new
     namespace, unshare(1) (since util-linux version 2.27) in turn  reverses
     the step performed by systemd(1), by making all mount points 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).
     For a discussion of propagation types when moving mounts (MS_MOVE)  and
     creating  bind  mounts (MS_BIND), see Documentation/filesystems/shared-
     subtree.txt.

SEE ALSO

     unshare(1),  clone(2),  mount(2),  setns(2),   umount(2),   unshare(2),
     proc(5), namespaces(7), user_namespaces(7)
     Documentation/filesystems/sharedsubtree.txt  in the kernel source tree.

COLOPHON

     This page is part of release 4.16 of the Linux  man-pages  project.   A
     description  of  the project, information about reporting bugs, and the
     latest    version    of    this    page,    can     be     found     at
     https://www.kernel.org/doc/man-pages/.

Linux 2018-04-30 MOUNT_NAMESPACES(7)

/data/webs/external/dokuwiki/data/pages/man/mount_namespaces.txt · Last modified: 2019/05/17 09:47 by 127.0.0.1

Was this page helpful?-10+1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki