mount_namespaces.7: Terminology clean-up: "mount point" ==> "mount"

Many times, this page use the terminology "mount point", where
"mount" would be better. A "mount point" is the location at which
a mount is attached. A "mount" is an association between a
filesystem and a mount point.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2021-08-18 01:34:54 +02:00
parent 5aea19ed35
commit 8c9a827429
1 changed files with 83 additions and 83 deletions

View File

@ -30,7 +30,7 @@ mount_namespaces \- overview of Linux mount namespaces
For an overview of namespaces, see For an overview of namespaces, see
.BR namespaces (7). .BR namespaces (7).
.PP .PP
Mount namespaces provide isolation of the list of mount points seen Mount namespaces provide isolation of the list of mounts seen
by the processes in each namespace instance. by the processes in each namespace instance.
Thus, the processes in each of the mount namespace instances Thus, the processes in each of the mount namespace instances
will see distinct single-directory hierarchies. will see distinct single-directory hierarchies.
@ -56,24 +56,24 @@ with the
.BR CLONE_NEWNS .BR CLONE_NEWNS
flag. flag.
When a new mount namespace is created, When a new mount namespace is created,
its mount point list is initialized as follows: its mount list is initialized as follows:
.IP * 3 .IP * 3
If the namespace is created using If the namespace is created using
.BR clone (2), .BR clone (2),
the mount point list of the child's namespace is a copy the mount list of the child's namespace is a copy
of the mount point list in the parent's namespace. of the mount list in the parent's namespace.
.IP * .IP *
If the namespace is created using If the namespace is created using
.BR unshare (2), .BR unshare (2),
the mount point list of the new namespace is a copy of the mount list of the new namespace is a copy of
the mount point list in the caller's previous mount namespace. the mount list in the caller's previous mount namespace.
.PP .PP
Subsequent modifications to the mount point list Subsequent modifications to the mount list
.RB ( mount (2) .RB ( mount (2)
and and
.BR umount (2)) .BR umount (2))
in either mount namespace will not (by default) affect the in either mount namespace will not (by default) affect the
mount point list seen in the other namespace mount list seen in the other namespace
(but see the following discussion of shared subtrees). (but see the following discussion of shared subtrees).
.\" .\"
.SH SHARED SUBTREES .SH SHARED SUBTREES
@ -92,31 +92,31 @@ between namespaces
.IR "peer group" .IR "peer group"
that are propagating events to one another). that are propagating events to one another).
.PP .PP
Each mount point is marked (via Each mount is marked (via
.BR mount (2)) .BR mount (2))
as having one of the following as having one of the following
.IR "propagation types" : .IR "propagation types" :
.TP .TP
.BR MS_SHARED .BR MS_SHARED
This mount point shares events with members of a peer group. This mount shares events with members of a peer group.
Mount and unmount events immediately under this mount point will propagate Mount and unmount events immediately under this mount will propagate
to the other mount points that are members of the peer group. to the other mounts that are members of the peer group.
.I Propagation .I Propagation
here means that the same mount or unmount will automatically occur here means that the same mount or unmount will automatically occur
under all of the other mount points in the peer group. under all of the other mounts in the peer group.
Conversely, mount and unmount events that take place under Conversely, mount and unmount events that take place under
peer mount points will propagate to this mount point. peer mounts will propagate to this mount.
.TP .TP
.BR MS_PRIVATE .BR MS_PRIVATE
This mount point is private; it does not have a peer group. This mount is private; it does not have a peer group.
Mount and unmount events do not propagate into or out of this mount point. Mount and unmount events do not propagate into or out of this mount.
.TP .TP
.BR MS_SLAVE .BR MS_SLAVE
Mount and unmount events propagate into this mount point from Mount and unmount events propagate into this mount from
a (master) shared peer group. a (master) shared peer group.
Mount and unmount events under this mount point do not propagate to any peer. Mount and unmount events under this mount do not propagate to any peer.
.IP .IP
Note that a mount point can be the slave of another peer group Note that a mount can be the slave of another peer group
while at the same time sharing mount and unmount events while at the same time sharing mount and unmount events
with a peer group of which it is a member. with a peer group of which it is a member.
(More precisely, one peer group can be the slave of another peer group.) (More precisely, one peer group can be the slave of another peer group.)
@ -145,37 +145,37 @@ For a discussion of the propagation type assigned to a new mount,
see NOTES. see NOTES.
.PP .PP
The propagation type is a per-mount-point setting; The propagation type is a per-mount-point setting;
some mount points may be marked as shared some mounts may be marked as shared
(with each shared mount point being a member of a distinct peer group), (with each shared mount being a member of a distinct peer group),
while others are private while others are private
(or slaved or unbindable). (or slaved or unbindable).
.PP .PP
Note that a mount's propagation type determines whether Note that a mount's propagation type determines whether
mounts and unmounts of mount points mounts and unmounts of mounts
.I "immediately under" .I "immediately under"
the mount point are propagated. the mount are propagated.
Thus, the propagation type does not affect propagation of events for Thus, the propagation type does not affect propagation of events for
grandchildren and further removed descendant mount points. grandchildren and further removed descendant mounts.
What happens if the mount point itself is unmounted is determined by What happens if the mount itself is unmounted is determined by
the propagation type that is in effect for the the propagation type that is in effect for the
.I parent .I parent
of the mount point. of the mount.
.PP .PP
Members are added to a Members are added to a
.IR "peer group" .IR "peer group"
when a mount point is marked as shared and either: when a mount is marked as shared and either:
.IP * 3 .IP * 3
the mount point is replicated during the creation of a new mount namespace; or the mount is replicated during the creation of a new mount namespace; or
.IP * .IP *
a new bind mount is created from the mount point. a new bind mount is created from the mount.
.PP .PP
In both of these cases, the new mount point joins the peer group In both of these cases, the new mount joins the peer group
of which the existing mount point is a member. of which the existing mount is a member.
.PP .PP
A new peer group is also created when a child mount point is created under A new peer group is also created when a child mount is created under
an existing mount point that is marked as shared. an existing mount that is marked as shared.
In this case, the new child mount point is also marked as shared and In this case, the new child mount is also marked as shared and
the resulting peer group consists of all the mount points the resulting peer group consists of all the mounts
that are replicated under the peers of parent mount. that are replicated under the peers of parent mount.
.PP .PP
A mount ceases to be a member of a peer group when either A mount ceases to be a member of a peer group when either
@ -183,7 +183,7 @@ the mount is explicitly unmounted,
or when the mount is implicitly unmounted because a mount namespace is removed or when the mount is implicitly unmounted because a mount namespace is removed
(because it has no more member processes). (because it has no more member processes).
.PP .PP
The propagation type of the mount points in a mount namespace The propagation type of the mounts in a mount namespace
can be discovered via the "optional fields" exposed in can be discovered via the "optional fields" exposed in
.IR /proc/[pid]/mountinfo . .IR /proc/[pid]/mountinfo .
(See (See
@ -193,11 +193,11 @@ The following tags can appear in the optional fields
for a record in that file: for a record in that file:
.TP .TP
.I shared:X .I shared:X
This mount point is shared in peer group This mount is shared in peer group
.IR X . .IR X .
Each peer group has a unique ID that is automatically Each peer group has a unique ID that is automatically
generated by the kernel, generated by the kernel,
and all mount points in the same peer group will show the same ID. and all mounts in the same peer group will show the same ID.
(These IDs are assigned starting from the value 1, (These IDs are assigned starting from the value 1,
and may be recycled when a peer group ceases to have any members.) and may be recycled when a peer group ceases to have any members.)
.TP .TP
@ -232,7 +232,7 @@ This is an unbindable mount.
If none of the above tags is present, then this is a private mount. If none of the above tags is present, then this is a private mount.
.SS MS_SHARED and MS_PRIVATE example .SS MS_SHARED and MS_PRIVATE example
Suppose that on a terminal in the initial mount namespace, Suppose that on a terminal in the initial mount namespace,
we mark one mount point as shared and another as private, we mark one mount as shared and another as private,
and then view the mounts in and then view the mounts in
.IR /proc/self/mountinfo : .IR /proc/self/mountinfo :
.PP .PP
@ -255,7 +255,7 @@ is a shared mount in peer group 1, and that
has no optional tags, indicating that it is a private mount. has no optional tags, indicating that it is a private mount.
The first two fields in each record in this file are the unique 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. 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 We can further inspect this file to see that the parent mount of
.IR /mntS .IR /mntS
and and
.IR /mntP .IR /mntP
@ -284,8 +284,8 @@ sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
.in .in
.PP .PP
The new mount namespace received a copy of the initial mount namespace's The new mount namespace received a copy of the initial mount namespace's
mount points. mounts.
These new mount points maintain the same propagation types, These new mounts maintain the same propagation types,
but have unique mount IDs. but have unique mount IDs.
(The (The
.IR \-\-propagation\ unchanged .IR \-\-propagation\ unchanged
@ -322,10 +322,10 @@ was created as shared (inheriting this setting from its parent mount) and
was created as a private mount. was created as a private mount.
.PP .PP
Returning to the first terminal and inspecting the set-up, Returning to the first terminal and inspecting the set-up,
we see that the new mount created under the shared mount point we see that the new mount created under the shared mount
.IR /mntS .IR /mntS
propagated to its peer mount (in the initial mount namespace), propagated to its peer mount (in the initial mount namespace),
but the new mount created under the private mount point but the new mount created under the private mount
.IR /mntP .IR /mntP
did not propagate: did not propagate:
.PP .PP
@ -339,7 +339,7 @@ sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
.in .in
.\" .\"
.SS MS_SLAVE example .SS MS_SLAVE example
Making a mount point a slave allows it to receive propagated Making a mount a slave allows it to receive propagated
mount and unmount events from a master shared peer group, mount and unmount events from a master shared peer group,
while preventing it from propagating events to that master. while preventing it from propagating events to that master.
This is useful if we want to (say) receive a mount event when This is useful if we want to (say) receive a mount event when
@ -349,7 +349,7 @@ but want to prevent mount and unmount events under the slave mount
from having side effects in other namespaces. from having side effects in other namespaces.
.PP .PP
We can demonstrate the effect of slaving by first marking We can demonstrate the effect of slaving by first marking
two mount points as shared in the initial mount namespace: two mounts as shared in the initial mount namespace:
.PP .PP
.in +4n .in +4n
.EX .EX
@ -362,7 +362,7 @@ sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
.in .in
.PP .PP
On a second terminal, On a second terminal,
we create a new mount namespace and inspect the mount points: we create a new mount namespace and inspect the mounts:
.PP .PP
.in +4n .in +4n
.EX .EX
@ -373,7 +373,7 @@ sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
.EE .EE
.in .in
.PP .PP
In the new mount namespace, we then mark one of the mount points as a slave: In the new mount namespace, we then mark one of the mounts as a slave:
.PP .PP
.in +4n .in +4n
.EX .EX
@ -403,7 +403,7 @@ sh2# \fBmount /dev/sda5 /mntY/b\fP
.EE .EE
.in .in
.PP .PP
When we inspect the state of the mount points in the new mount namespace, When we inspect the state of the mounts in the new mount namespace,
we see that we see that
.IR /mntX/a .IR /mntX/a
was created as a new shared mount was created as a new shared mount
@ -439,7 +439,7 @@ sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
.EE .EE
.in .in
.PP .PP
Now we create a new mount point under Now we create a new mount under
.IR /mntY .IR /mntY
in the first shell: in the first shell:
.PP .PP
@ -455,9 +455,9 @@ sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
.EE .EE
.in .in
.PP .PP
When we examine the mount points in the second mount namespace, When we examine the mounts in the second mount namespace,
we see that in this case the new mount has been propagated we see that in this case the new mount has been propagated
to the slave mount point, to the slave mount,
and that the new mount is itself a slave mount (to peer group 4): and that the new mount is itself a slave mount (to peer group 4):
.PP .PP
.in +4n .in +4n
@ -473,11 +473,11 @@ sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
.\" .\"
.SS MS_UNBINDABLE example .SS MS_UNBINDABLE example
One of the primary purposes of unbindable mounts is to avoid One of the primary purposes of unbindable mounts is to avoid
the "mount point explosion" problem when repeatedly performing bind mounts the "mount explosion" problem when repeatedly performing bind mounts
of a higher-level subtree at a lower-level mount point. of a higher-level subtree at a lower-level mount.
The problem is illustrated by the following shell session. The problem is illustrated by the following shell session.
.PP .PP
Suppose we have a system with the following mount points: Suppose we have a system with the following mounts:
.PP .PP
.in +4n .in +4n
.EX .EX
@ -490,7 +490,7 @@ Suppose we have a system with the following mount points:
.PP .PP
Suppose furthermore that we wish to recursively bind mount Suppose furthermore that we wish to recursively bind mount
the root directory under several users' home directories. the root directory under several users' home directories.
We do this for the first user, and inspect the mount points: We do this for the first user, and inspect the mounts:
.PP .PP
.in +4n .in +4n
.EX .EX
@ -605,8 +605,8 @@ Now we create unbindable recursive bind mounts for the other two users:
.EE .EE
.in .in
.PP .PP
Upon examining the list of mount points, Upon examining the list of mounts,
we see there has been no explosion of mount points, we see there has been no explosion of mounts,
because the unbindable mounts were not replicated because the unbindable mounts were not replicated
under each user's directory: under each user's directory:
.PP .PP
@ -632,7 +632,7 @@ under each user's directory:
The following table shows the effect that applying a new propagation type The following table shows the effect that applying a new propagation type
(i.e., (i.e.,
.IR "mount \-\-make\-xxxx") .IR "mount \-\-make\-xxxx")
has on the existing propagation type of a mount point. has on the existing propagation type of a mount.
The rows correspond to existing propagation types, The rows correspond to existing propagation types,
and the columns are the new propagation settings. and the columns are the new propagation settings.
For reasons of space, "private" is abbreviated as "priv" and For reasons of space, "private" is abbreviated as "priv" and
@ -667,9 +667,9 @@ mount \-\-bind A/a B/b
.PP .PP
Here, Here,
.I A .I A
is the source mount point, is the source mount,
.I B .I B
is the destination mount point, is the destination mount,
.I a .I a
is a subdirectory path under the mount point is a subdirectory path under the mount point
.IR A , .IR A ,
@ -679,7 +679,7 @@ is a subdirectory path under the mount point
.IR B . .IR B .
The propagation type of the resulting mount, The propagation type of the resulting mount,
.IR B/b , .IR B/b ,
depends on the propagation types of the mount points depends on the propagation types of the mounts
.IR A .IR A
and and
.IR B , .IR B ,
@ -715,15 +715,15 @@ mount \-\-move A B/b
.PP .PP
Here, Here,
.I A .I A
is the source mount point, is the source mount,
.I B .I B
is the destination mount point, and is the destination mount, and
.I b .I b
is a subdirectory path under the mount point is a subdirectory path under the mount point
.IR B . .IR B .
The propagation type of the resulting mount, The propagation type of the resulting mount,
.IR B/b , .IR B/b ,
depends on the propagation types of the mount points depends on the propagation types of the mounts
.IR A .IR A
and and
.IR B , .IR B ,
@ -747,7 +747,7 @@ For further details, see
in the kernel source tree. in the kernel source tree.
.\" .\"
.SS Mount semantics .SS Mount semantics
Suppose that we use the following command to create a mount point: Suppose that we use the following command to create a mount:
.PP .PP
.in +4n .in +4n
.EX .EX
@ -757,7 +757,7 @@ mount device B/b
.PP .PP
Here, Here,
.I B .I B
is the destination mount point, and is the destination mount, and
.I b .I b
is a subdirectory path under the mount point is a subdirectory path under the mount point
.IR B . .IR B .
@ -768,7 +768,7 @@ where the propagation type of the source mount
is considered always to be private. is considered always to be private.
.\" .\"
.SS Unmount semantics .SS Unmount semantics
Suppose that we use the following command to tear down a mount point: Suppose that we use the following command to tear down a mount:
.PP .PP
.in +4n .in +4n
.EX .EX
@ -778,7 +778,7 @@ unmount A
.PP .PP
Here, Here,
.I A .I A
is a mount point on is a mount on
.IR B/b , .IR B/b ,
where where
.I B .I B
@ -871,7 +871,7 @@ onto
.EE .EE
.in .in
.PP .PP
Initially, these two mount points are in the same peer group, Initially, these two mounts are in the same peer group,
but we then make the but we then make the
.IR /tmp/etc .IR /tmp/etc
a slave of a slave of
@ -896,7 +896,7 @@ Then we bind mount
.IR /tmp/etc .IR /tmp/etc
onto onto
.IR /mnt/tmp/etc . .IR /mnt/tmp/etc .
Again, the two mount points are initially in the same peer group, Again, the two mounts are initially in the same peer group,
but we then make but we then make
.IR /mnt/tmp/etc .IR /mnt/tmp/etc
a slave of a slave of
@ -965,9 +965,9 @@ Mount namespaces first appeared in Linux 2.4.19.
Namespaces are a Linux-specific feature. Namespaces are a Linux-specific feature.
.\" .\"
.SH NOTES .SH NOTES
The propagation type assigned to a new mount point depends The propagation type assigned to a new mount depends
on the propagation type of the parent mount. on the propagation type of the parent mount.
If the mount point has a parent (i.e., it is a non-root mount If the mount has a parent (i.e., it is a non-root mount
point) and the propagation type of the parent is point) and the propagation type of the parent is
.BR MS_SHARED , .BR MS_SHARED ,
then the propagation type of the new mount is also then the propagation type of the new mount is also
@ -976,13 +976,13 @@ Otherwise, the propagation type of the new mount is
.BR MS_PRIVATE . .BR MS_PRIVATE .
.PP .PP
Notwithstanding the fact that the default propagation type Notwithstanding the fact that the default propagation type
for new mount points is in many cases for new mount is in many cases
.BR MS_PRIVATE , .BR MS_PRIVATE ,
.BR MS_SHARED .BR MS_SHARED
is typically more useful. is typically more useful.
For this reason, For this reason,
.BR systemd (1) .BR systemd (1)
automatically remounts all mount points as automatically remounts all mounts as
.BR MS_SHARED .BR MS_SHARED
on system startup. on system startup.
Thus, on most modern systems, the default propagation type is in practice Thus, on most modern systems, the default propagation type is in practice
@ -991,14 +991,14 @@ Thus, on most modern systems, the default propagation type is in practice
Since, when one uses Since, when one uses
.BR unshare (1) .BR unshare (1)
to create a mount namespace, to create a mount namespace,
the goal is commonly to provide full isolation of the mount points the goal is commonly to provide full isolation of the mounts
in the new namespace, in the new namespace,
.BR unshare (1) .BR unshare (1)
(since (since
.IR util\-linux .IR util\-linux
version 2.27) in turn reverses the step performed by version 2.27) in turn reverses the step performed by
.BR systemd (1), .BR systemd (1),
by making all mount points private in the new namespace. by making all mounts private in the new namespace.
That is, That is,
.BR unshare (1) .BR unshare (1)
performs the equivalent of the following in the new mount namespace: performs the equivalent of the following in the new mount namespace:
@ -1022,7 +1022,7 @@ may desire to prevent propagation of mount events to other mount namespaces
(as is done by (as is done by
.BR unshare (1)). .BR unshare (1)).
This can be done by changing the propagation type of This can be done by changing the propagation type of
mount points in the new namespace to either mounts in the new namespace to either
.B MS_SLAVE .B MS_SLAVE
or or
.BR MS_PRIVATE , .BR MS_PRIVATE ,
@ -1048,9 +1048,9 @@ Note the following points with respect to mount namespaces:
.IP * 3 .IP * 3
Each mount namespace has an owner user namespace. Each mount namespace has an owner user namespace.
As explained above, when a new mount namespace is created, As explained above, when a new mount namespace is created,
its mount point list is initialized as a copy of the mount point list its mount list is initialized as a copy of the mount list
of another mount namespace. of another mount namespace.
If the new namespace and the namespace from which the mount point list If the new namespace and the namespace from which the mount list
was copied are owned by different user namespaces, was copied are owned by different user namespaces,
then the new mount namespace is considered then the new mount namespace is considered
.IR "less privileged" . .IR "less privileged" .
@ -1139,7 +1139,7 @@ In the new mount namespace,
the propagation type of all mounts is set to private. the propagation type of all mounts is set to private.
We then create a shared bind mount at We then create a shared bind mount at
.IR /mnt , .IR /mnt ,
and a small hierarchy of mount points underneath that mount point. and a small hierarchy of mounts underneath that mount.
.IP .IP
.in +4n .in +4n
.EX .EX
@ -1162,7 +1162,7 @@ ns1# \fBgrep /mnt /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
Continuing in the same shell session, Continuing in the same shell session,
we then create a second shell in a new user namespace and a new we then create a second shell in a new user namespace and a new
(less privileged) mount namespace and (less privileged) mount namespace and
check the state of the propagated mount points rooted at check the state of the propagated mounts rooted at
.IR /mnt . .IR /mnt .
.IP .IP
.in +4n .in +4n
@ -1176,7 +1176,7 @@ ns2# \fBgrep /mnt /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
.EE .EE
.in .in
.IP .IP
Of note in the above output is that the propagation type of the mount point Of note in the above output is that the propagation type of the mount
.I /mnt .I /mnt
has been reduced to slave, as explained near the start of this subsection. has been reduced to slave, as explained near the start of this subsection.
This means that submount events will propagate from the master This means that submount events will propagate from the master