-.\" Copyright (c) 2016 by Michael Kerrisk <mtk.manpages@gmail.com>
+.\" Copyright (c) 2016, 2019 by Michael Kerrisk <mtk.manpages@gmail.com>
.\"
.\" %%%LICENSE_START(VERBATIM)
.\" Permission is granted to make and distribute verbatim copies of this
.\" %%%LICENSE_END
.\"
.\"
-.TH MOUNT_NAMESPACES 7 2016-07-17 "Linux" "Linux Programmer's Manual"
+.TH MOUNT_NAMESPACES 7 2018-04-30 "Linux" "Linux Programmer's Manual"
.SH NAME
mount_namespaces \- overview of Linux mount namespaces
.SH DESCRIPTION
For an overview of namespaces, see
.BR namespaces (7).
-
+.PP
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.
-
+.PP
The views provided by the
.IR /proc/[pid]/mounts ,
.IR /proc/[pid]/mountinfo ,
resides.
(All of the processes that reside in the same mount namespace
will see the same view in these files.)
-
+.PP
When a process creates a new mount namespace using
.BR clone (2)
or
mount point list seen in the other namespace
(but see the following discussion of shared subtrees).
.\"
+.\" ============================================================
+.\"
+.SS Restrictions on mount namespaces
+Note the following points with respect to mount namespaces:
+.IP * 3
+A mount namespace has an owner user namespace.
+A mount namespace whose owner user namespace is different from
+the owner user namespace of its parent mount namespace is
+considered a less privileged mount namespace.
+.IP *
+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 namespaces.
+.IP *
+.\" FIXME .
+.\" What does "come as a single unit from more privileged mount" mean?
+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
+.BR unshare (2)
+.B 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.)
+.IP *
+The
+.BR mount (2)
+flags
+.BR MS_RDONLY ,
+.BR MS_NOSUID ,
+.BR MS_NOEXEC ,
+and the "atime" flags
+.RB ( MS_NOATIME ,
+.BR MS_NODIRATIME ,
+.BR MS_RELATIME )
+settings become locked
+.\" commit 9566d6742852c527bf5af38af5cbb878dad75705
+.\" Author: Eric W. Biederman <ebiederm@xmission.com>
+.\" Date: Mon Jul 28 17:26:07 2014 -0700
+.\"
+.\" mnt: Correct permission checks in do_remount
+.\"
+when propagated from a more privileged to
+a less privileged mount namespace,
+and may not be changed in the less privileged mount namespace.
+.IP *
+.\" (As of 3.18-rc1 (in Al Viro's 2014-08-30 vfs.git#for-next tree))
+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
+.RB ( 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.
+.IP
+Previously (before Linux 3.18),
+.\" mtk: The change was in Linux 3.18, I think, with this commit:
+.\" commit 8ed936b5671bfb33d89bc60bdcc7cf0470ba52fe
+.\" Author: Eric W. Biederman <ebiederman@twitter.com>
+.\" Date: Tue Oct 1 18:33:48 2013 -0700
+.\"
+.\" vfs: Lazily remove mounts on unlinked files and directories.
+attempting to unlink, rename, or remove a file or directory
+that was a mount point in another mount namespace would result in the error
+.BR 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).
+.\"
.SH SHARED SUBTREES
After the implementation of mount namespaces was completed,
experience showed that the isolation that they provided was,
(or, more precisely, between the members of a
.IR "peer group"
that are propagating events to one another).
-
+.PP
Each mount point is marked (via
.BR mount (2))
as having one of the following
.BR 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.
-This is the default propagation type for newly created mount points
-(but see NOTES).
.TP
.BR 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.
-
+.IP
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.
with the
.BR MS_BIND
flag) will fail.
-
+.IP
When a recursive bind mount
.RB ( mount (2)
with the
(i.e., not replicated)
when replicating that subtree to produce the target subtree.
.PP
+For a discussion of the propagation type assigned to a new mount,
+see NOTES.
+.PP
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 unbindable).
-
+.PP
Note that a mount's propagation type determines whether
mounts and unmounts of mount points
.I "immediately under"
the propagation type that is in effect for the
.I parent
of the mount point.
-
+.PP
Members are added to a
.IR "peer group"
when a mount point is marked as shared and either:
.PP
In both of these cases, the new mount point joins the peer group
of which the existing mount point is a member.
+.PP
+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.
+.PP
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).
-
+.PP
The propagation type of the mount points in a mount namespace
can be discovered via the "optional fields" exposed in
.IR /proc/[pid]/mountinfo .
we mark one mount point as shared and another as private,
and then view the mounts in
.IR /proc/self/mountinfo :
-
-.nf
+.PP
.in +4n
+.EX
sh1# \fBmount \-\-make\-shared /mntS\fP
sh1# \fBmount \-\-make\-private /mntP\fP
sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
77 61 8:17 / /mntS rw,relatime shared:1
83 61 8:15 / /mntP rw,relatime
+.EE
.in
-.fi
-
+.PP
From the
.IR /proc/self/mountinfo
output, we see that
is the root directory,
.IR / ,
which is mounted as private:
-
-.nf
+.PP
.in +4n
+.EX
sh1# \fBcat /proc/self/mountinfo | awk \(aq$1 == 61\(aq | sed \(aqs/ \- .*//\(aq\fP
61 0 8:2 / / rw,relatime
+.EE
.in
-.fi
-
+.PP
On a second terminal,
we create a new mount namespace where we run a second shell
and inspect the mounts:
-
-.nf
+.PP
.in +4n
+.EX
$ \fBPS1=\(aqsh2# \(aq sudo unshare \-m \-\-propagation unchanged sh\fP
sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
222 145 8:17 / /mntS rw,relatime shared:1
225 145 8:15 / /mntP rw,relatime
+.EE
.in
-.fi
-
+.PP
The new mount namespace received a copy of the initial mount namespace's
mount points.
These new mount points maintain the same propagation types,
from marking all mounts as private when creating a new mount namespace,
.\" Since util-linux 2.27
which it does by default.)
-
+.PP
In the second terminal, we then create submounts under each of
.IR /mntS
and
.IR /mntP
and inspect the set-up:
-
-.nf
+.PP
.in +4n
+.EX
sh2# \fBmkdir /mntS/a\fP
sh2# \fBmount /dev/sdb6 /mntS/a\fP
sh2# \fBmkdir /mntP/b\fP
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
+.EE
.in
-.fi
-
+.PP
From the above, it can be seen that
.IR /mntS/a
was created as shared (inheriting this setting from its parent mount) and
.IR /mntP/b
was created as a private mount.
-
+.PP
Returning to the first terminal and inspecting the set-up,
we see that the new mount created under the shared mount point
.IR /mntS
but the new mount created under the private mount point
.IR /mntP
did not propagate:
-
-.nf
+.PP
.in +4n
+.EX
sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
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
+.EE
.in
-.fi
.\"
.SS MS_SLAVE example
Making a mount point a slave allows it to receive propagated
(in another mount namespace),
but want to prevent mount and unmount events under the slave mount
from having side effects in other namespaces.
-
+.PP
We can demonstrate the effect of slaving by first marking
two mount points as shared in the initial mount namespace:
-
-.nf
+.PP
.in +4n
+.EX
sh1# \fBmount \-\-make\-shared /mntX\fP
sh1# \fBmount \-\-make\-shared /mntY\fP
sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
132 83 8:23 / /mntX rw,relatime shared:1
133 83 8:22 / /mntY rw,relatime shared:2
+.EE
.in
-.fi
-
+.PP
On a second terminal,
we create a new mount namespace and inspect the mount points:
-
-.nf
+.PP
.in +4n
+.EX
sh2# \fBunshare \-m \-\-propagation unchanged sh\fP
sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime shared:2
+.EE
.in
-.fi
-
+.PP
In the new mount namespace, we then mark one of the mount points as a slave:
-
-.nf
+.PP
.in +4n
+.EX
sh2# \fBmount \-\-make\-slave /mntY\fP
sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime master:2
+.EE
.in
-.fi
-
+.PP
From the above output, we see that
.IR /mntY
is now a slave mount that is receiving propagation events from
the shared peer group with the ID 2.
-
+.PP
Continuing in the new namespace, we create submounts under each of
.IR /mntX
and
.IR /mntY :
-
-.nf
+.PP
.in +4n
+.EX
sh2# \fBmkdir /mntX/a\fP
sh2# \fBmount /dev/sda3 /mntX/a\fP
sh2# \fBmkdir /mntY/b\fP
sh2# \fBmount /dev/sda5 /mntY/b\fP
+.EE
.in
-.fi
-
+.PP
When we inspect the state of the mount points in the new mount namespace,
we see that
.IR /mntX/a
(inheriting the "shared" setting from its parent mount) and
.IR /mntY/b
was created as a private mount:
-
-.nf
+.PP
.in +4n
+.EX
sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
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
+.EE
.in
-.fi
-
+.PP
Returning to the first terminal (in the initial mount namespace),
we see that the mount
.IR /mntX/a
but the mount
.IR /mntY/b
was not propagated:
-
-.nf
+.PP
.in +4n
+.EX
sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
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
+.EE
.in
-.fi
-
+.PP
Now we create a new mount point under
.IR /mntY
in the first shell:
-
-.nf
+.PP
.in +4n
+.EX
sh1# \fBmkdir /mntY/c\fP
sh1# \fBmount /dev/sda1 /mntY/c\fP
sh1# \fBcat /proc/self/mountinfo | grep '/mnt' | sed 's/ \- .*//'\fP
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
+.EE
.in
-.fi
-
+.PP
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):
-
-.nf
+.PP
.in +4n
+.EX
sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
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
+.EE
.in
-.fi
.\"
.SS 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.
-
+.PP
Suppose we have a system with the following mount points:
-
-.nf
+.PP
.in +4n
+.EX
# \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
+.EE
.in
-.fi
-
+.PP
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:
-
-.nf
+.PP
.in +4n
+.EX
# \fBmount \-\-rbind / /home/cecilia/\fP
# \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
/dev/sda1 on /
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY
+.EE
.in
-.fi
-
+.PP
When we repeat this operation for the second user,
we start to see the explosion problem:
-
-.nf
+.PP
.in +4n
+.EX
# \fBmount \-\-rbind / /home/henry\fP
# \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
/dev/sda1 on /
/dev/sda1 on /home/henry/home/cecilia
/dev/sdb6 on /home/henry/home/cecilia/mntX
/dev/sdb7 on /home/henry/home/cecilia/mntY
+.EE
.in
-.fi
-
+.PP
Under
.IR /home/henry ,
we have not only recursively added the
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:
-
-.nf
+.PP
.in +4n
+.EX
# \fBmount \-\-rbind / /home/otto\fP
# \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
/dev/sda1 on /
/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
+.EE
.in
-.fi
-
+.PP
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:
-
-.nf
+.PP
.in +4n
+.EX
# \fBmount \-\-rbind \-\-make\-unbindable / /home/cecilia\fP
+.EE
.in
-.fi
-
+.PP
Before going further, we show that unbindable mounts are indeed unbindable:
-
-.nf
+.PP
.in +4n
+.EX
# \fBmkdir /mntZ\fP
# \fBmount \-\-bind /home/cecilia /mntZ\fP
mount: wrong fs type, bad option, bad superblock on /home/cecilia,
In some cases useful info is found in syslog \- try
dmesg | tail or so.
+.EE
.in
-.fi
-
+.PP
Now we create unbindable recursive bind mounts for the other two users:
-
-.nf
+.PP
.in +4n
+.EX
# \fBmount \-\-rbind \-\-make\-unbindable / /home/henry\fP
# \fBmount \-\-rbind \-\-make\-unbindable / /home/otto\fP
+.EE
.in
-.fi
-
+.PP
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:
-
-.nf
+.PP
.in +4n
+.EX
# \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sda1 on /home/otto
/dev/sdb6 on /home/otto/mntX
/dev/sdb7 on /home/otto/mntY
+.EE
.in
-.fi
.\"
.SS Propagation type transitions
The following table shows the effect that applying a new propagation type
private shared priv [2] priv unbind
unbindable shared unbind [2] priv unbind
.TE
-
+.sp 1
Note the following details to the table:
.IP [1] 4
If a shared mount is the only mount in its peer group,
.\"
.SS Bind (MS_BIND) semantics
Suppose that the following command is performed:
-
- mount \-\-bind A/a B/b
-
+.PP
+.in +4n
+.EX
+mount \-\-bind A/a B/b
+.EE
+.in
+.PP
Here,
.I A
is the source mount point,
and
.IR B ,
and is summarized in the following table.
-
+.PP
.TS
lb2 lb1 lb2 lb2 lb2 lb0
lb2 lb1 lb2 lb2 lb2 lb0
dest(B) shared | shared shared slave+shared invalid
nonshared | shared private slave invalid
.TE
-
+.sp 1
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.)
-
+.PP
For further details, see
.I Documentation/filesystems/sharedsubtree.txt
in the kernel source tree.
.\"
.SS Move (MS_MOVE) semantics
Suppose that the following command is performed:
-
- mount \-\-move A B/b
-
+.PP
+.in +4n
+.EX
+mount \-\-move A B/b
+.EE
+.in
+.PP
Here,
.I A
is the source mount point,
and
.IR B ,
and is summarized in the following table.
-
+.PP
.TS
lb2 lb1 lb2 lb2 lb2 lb0
lb2 lb1 lb2 lb2 lb2 lb0
dest(B) shared | shared shared slave+shared invalid
nonshared | shared private slave unbindable
.TE
-
+.sp 1
Note: moving a mount that resides under a shared mount is invalid.
-
+.PP
For further details, see
.I Documentation/filesystems/sharedsubtree.txt
in the kernel source tree.
.\"
.SS Mount semantics
Suppose that we use the following command to create a mount point:
-
- mount device B/b
-
+.PP
+.in +4n
+.EX
+mount device B/b
+.EE
+.in
+.PP
Here,
.I B
is the destination mount point, and
.\"
.SS Unmount semantics
Suppose that we use the following command to tear down a mount point:
-
- unmount A
-
+.PP
+.in +4n
+.EX
+unmount A
+.EE
+.in
+.PP
Here,
.I A
is a mount point on
the filesystem root directory)
and so cannot determine the
chain of propagation between the mounts it can see.
-
+.PP
In the following example, we first create a two-link master-slave chain
between the mounts
.IR /mnt ,
creating a situation where the master of
.IR /mnt/tmp/etc
is not reachable from the (new) root directory of the process.
-
+.PP
First, we bind mount the root directory onto
.IR /mnt
and then bind mount
.BR proc (5)
filesystem remains visible at the correct location
in the chroot-ed environment.
-
-.nf
+.PP
.in +4n
+.EX
# \fBmkdir \-p /mnt/proc\fP
# \fBmount \-\-bind / /mnt\fP
# \fBmount \-\-bind /proc /mnt/proc\fP
+.EE
.in
-.fi
-
+.PP
Next, we ensure that the
.IR /mnt
mount is a shared mount in a new peer group (with no peers):
-
-.nf
+.PP
.in +4n
+.EX
# \fBmount \-\-make\-private /mnt\fP # Isolate from any previous peer group
# \fBmount \-\-make\-shared /mnt\fP
# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
239 61 8:2 / /mnt ... shared:102
248 239 0:4 / /mnt/proc ... shared:5
+.EE
.in
-.fi
-
+.PP
Next, we bind mount
.IR /mnt/etc
onto
.IR /tmp/etc :
-
-.nf
+.PP
.in +4n
+.EX
# \fBmkdir \-p /tmp/etc\fP
# \fBmount \-\-bind /mnt/etc /tmp/etc\fP
# \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP
239 61 8:2 / /mnt ... shared:102
248 239 0:4 / /mnt/proc ... shared:5
267 40 8:2 /etc /tmp/etc ... shared:102
+.EE
.in
-.fi
-
+.PP
Initially, these two mount points are in the same peer group,
but we then make the
.IR /tmp/etc
.IR /tmp/etc
shared as well,
so that it can propagate events to the next slave in the chain:
-
-.nf
+.PP
.in +4n
+.EX
# \fBmount \-\-make\-slave /tmp/etc\fP
# \fBmount \-\-make\-shared /tmp/etc\fP
# \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP
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
+.EE
.in
-.fi
-
+.PP
Then we bind mount
.IR /tmp/etc
onto
.IR /mnt/tmp/etc
a slave of
.IR /tmp/etc :
-
-.nf
+.PP
.in +4n
+.EX
# \fBmkdir \-p /mnt/tmp/etc\fP
# \fBmount \-\-bind /tmp/etc /mnt/tmp/etc\fP
# \fBmount \-\-make\-slave /mnt/tmp/etc\fP
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
-
+.EE
.in
-.fi
+.PP
From the above, we see that
.IR /mnt
is the master of the slave
.IR /tmp/etc ,
which in turn is the master of the slave
.IR /mnt/tmp/etc .
-
+.PP
We then
.BR chroot (1)
to the
.IR /mnt
directory, which renders the mount with ID 267 unreachable
from the (new) root directory:
-
-.nf
+.PP
.in +4n
+.EX
# \fBchroot /mnt\fP
+.EE
.in
-.fi
-
+.PP
When we examine the state of the mounts inside the chroot-ed environment,
we see the following:
-
-.nf
+.PP
.in +4n
+.EX
# \fBcat /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
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
+.EE
.in
-.fi
-
+.PP
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
Namespaces are a Linux-specific feature.
.\"
.SH NOTES
-The kernel default propagation type for mount points is
+The propagation type assigned to a new mount point depends
+on the propagation type of the parent mount.
+If the mount point has a parent (i.e., it is a non-root mount
+point) and the propagation type of the parent is
+.BR MS_SHARED ,
+then the propagation type of the new mount is also
+.BR MS_SHARED .
+Otherwise, the propagation type of the new mount is
.BR MS_PRIVATE .
-However,
+.PP
+Notwithstanding the fact that the default propagation type
+for new mount points is in many cases
+.BR MS_PRIVATE ,
.BR MS_SHARED
-is typically more commonly required, and for this reason,
+is typically more useful.
+For this reason,
.BR systemd (1)
automatically remounts all mount points as
.BR MS_SHARED
on system startup.
-
+Thus, on most modern systems, the default propagation type is in practice
+.BR MS_SHARED .
+.PP
Since, when one uses
.BR unshare (1)
to create a mount namespace,
That is,
.BR unshare (1)
performs the equivalent of the following in the new mount namespace:
-
- mount \-\-make\-rprivate /
-
+.PP
+.in +4n
+.EX
+mount \-\-make\-rprivate /
+.EE
+.in
+.PP
To prevent this, one can use the
.IR "\-\-propagation\ unchanged"
option to
.BR unshare (1).
+.PP
+For a discussion of propagation types when moving mounts
+.RB ( MS_MOVE )
+and creating bind mounts
+.RB ( MS_BIND ),
+see
+.IR Documentation/filesystems/sharedsubtree.txt .
.SH SEE ALSO
.BR unshare (1),
.BR clone (2),
.BR mount (2),
+.BR pivot_root (2),
.BR setns (2),
.BR umount (2),
.BR unshare (2),
.BR proc (5),
-.BR namespaces (7)
-
+.BR namespaces (7),
+.BR user_namespaces (7),
+.BR findmnt (8),
+.BR pivot_root (8)
+.PP
.IR Documentation/filesystems/sharedsubtree.txt
in the kernel source tree.
projects / thirdparty / man-pages.git / blobdiff