mirror of https://github.com/mkerrisk/man-pages
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
parent
5aea19ed35
commit
8c9a827429
|
|
@ -30,7 +30,7 @@ mount_namespaces \- overview of Linux mount namespaces
|
|||
For an overview of namespaces, see
|
||||
.BR namespaces (7).
|
||||
.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.
|
||||
Thus, the processes in each of the mount namespace instances
|
||||
will see distinct single-directory hierarchies.
|
||||
|
|
@ -56,24 +56,24 @@ with the
|
|||
.BR CLONE_NEWNS
|
||||
flag.
|
||||
When a new mount namespace is created,
|
||||
its mount point list is initialized as follows:
|
||||
its mount list is initialized as follows:
|
||||
.IP * 3
|
||||
If the namespace is created using
|
||||
.BR clone (2),
|
||||
the mount point list of the child's namespace is a copy
|
||||
of the mount point list in the parent's namespace.
|
||||
the mount list of the child's namespace is a copy
|
||||
of the mount list in the parent's namespace.
|
||||
.IP *
|
||||
If the namespace is created using
|
||||
.BR unshare (2),
|
||||
the mount point list of the new namespace is a copy of
|
||||
the mount point list in the caller's previous mount namespace.
|
||||
the mount list of the new namespace is a copy of
|
||||
the mount list in the caller's previous mount namespace.
|
||||
.PP
|
||||
Subsequent modifications to the mount point list
|
||||
Subsequent modifications to the mount list
|
||||
.RB ( mount (2)
|
||||
and
|
||||
.BR umount (2))
|
||||
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).
|
||||
.\"
|
||||
.SH SHARED SUBTREES
|
||||
|
|
@ -92,31 +92,31 @@ between namespaces
|
|||
.IR "peer group"
|
||||
that are propagating events to one another).
|
||||
.PP
|
||||
Each mount point is marked (via
|
||||
Each mount is marked (via
|
||||
.BR mount (2))
|
||||
as having one of the following
|
||||
.IR "propagation types" :
|
||||
.TP
|
||||
.BR 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.
|
||||
This mount shares events with members of a peer group.
|
||||
Mount and unmount events immediately under this mount will propagate
|
||||
to the other mounts that are members of the peer group.
|
||||
.I Propagation
|
||||
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
|
||||
peer mount points will propagate to this mount point.
|
||||
peer mounts will propagate to this mount.
|
||||
.TP
|
||||
.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 mount is private; it does not have a peer group.
|
||||
Mount and unmount events do not propagate into or out of this mount.
|
||||
.TP
|
||||
.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.
|
||||
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
|
||||
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
|
||||
with a peer group of which it is a member.
|
||||
(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.
|
||||
.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),
|
||||
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).
|
||||
.PP
|
||||
Note that a mount's propagation type determines whether
|
||||
mounts and unmounts of mount points
|
||||
mounts and unmounts of mounts
|
||||
.I "immediately under"
|
||||
the mount point are propagated.
|
||||
the mount are propagated.
|
||||
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
|
||||
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
|
||||
.I parent
|
||||
of the mount point.
|
||||
of the mount.
|
||||
.PP
|
||||
Members are added to a
|
||||
.IR "peer group"
|
||||
when a mount point is marked as shared and either:
|
||||
when a mount is marked as shared and either:
|
||||
.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 *
|
||||
a new bind mount is created from the mount point.
|
||||
a new bind mount is created from the mount.
|
||||
.PP
|
||||
In both of these cases, the new mount point joins the peer group
|
||||
of which the existing mount point is a member.
|
||||
In both of these cases, the new mount joins the peer group
|
||||
of which the existing mount 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
|
||||
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 mount.
|
||||
.PP
|
||||
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
|
||||
(because it has no more member processes).
|
||||
.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
|
||||
.IR /proc/[pid]/mountinfo .
|
||||
(See
|
||||
|
|
@ -193,11 +193,11 @@ The following tags can appear in the optional fields
|
|||
for a record in that file:
|
||||
.TP
|
||||
.I shared:X
|
||||
This mount point is shared in peer group
|
||||
This mount is shared in peer group
|
||||
.IR 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.
|
||||
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.)
|
||||
.TP
|
||||
|
|
@ -232,7 +232,7 @@ This is an unbindable mount.
|
|||
If none of the above tags is present, then this is a private mount.
|
||||
.SS 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,
|
||||
we mark one mount as shared and another as private,
|
||||
and then view the mounts in
|
||||
.IR /proc/self/mountinfo :
|
||||
.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.
|
||||
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
|
||||
We can further inspect this file to see that the parent mount of
|
||||
.IR /mntS
|
||||
and
|
||||
.IR /mntP
|
||||
|
|
@ -284,8 +284,8 @@ sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
|
|||
.in
|
||||
.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,
|
||||
mounts.
|
||||
These new mounts maintain the same propagation types,
|
||||
but have unique mount IDs.
|
||||
(The
|
||||
.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.
|
||||
.PP
|
||||
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
|
||||
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
|
||||
did not propagate:
|
||||
.PP
|
||||
|
|
@ -339,7 +339,7 @@ sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
|
|||
.in
|
||||
.\"
|
||||
.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,
|
||||
while preventing it from propagating events to that master.
|
||||
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.
|
||||
.PP
|
||||
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
|
||||
.in +4n
|
||||
.EX
|
||||
|
|
@ -362,7 +362,7 @@ sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
|
|||
.in
|
||||
.PP
|
||||
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
|
||||
.in +4n
|
||||
.EX
|
||||
|
|
@ -373,7 +373,7 @@ sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
|
|||
.EE
|
||||
.in
|
||||
.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
|
||||
.in +4n
|
||||
.EX
|
||||
|
|
@ -403,7 +403,7 @@ sh2# \fBmount /dev/sda5 /mntY/b\fP
|
|||
.EE
|
||||
.in
|
||||
.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
|
||||
.IR /mntX/a
|
||||
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
|
||||
.in
|
||||
.PP
|
||||
Now we create a new mount point under
|
||||
Now we create a new mount under
|
||||
.IR /mntY
|
||||
in the first shell:
|
||||
.PP
|
||||
|
|
@ -455,9 +455,9 @@ sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
|
|||
.EE
|
||||
.in
|
||||
.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
|
||||
to the slave mount point,
|
||||
to the slave mount,
|
||||
and that the new mount is itself a slave mount (to peer group 4):
|
||||
.PP
|
||||
.in +4n
|
||||
|
|
@ -473,11 +473,11 @@ sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
|
|||
.\"
|
||||
.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 "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.
|
||||
.PP
|
||||
Suppose we have a system with the following mount points:
|
||||
Suppose we have a system with the following mounts:
|
||||
.PP
|
||||
.in +4n
|
||||
.EX
|
||||
|
|
@ -490,7 +490,7 @@ Suppose we have a system with the following mount points:
|
|||
.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:
|
||||
We do this for the first user, and inspect the mounts:
|
||||
.PP
|
||||
.in +4n
|
||||
.EX
|
||||
|
|
@ -605,8 +605,8 @@ Now we create unbindable recursive bind mounts for the other two users:
|
|||
.EE
|
||||
.in
|
||||
.PP
|
||||
Upon examining the list of mount points,
|
||||
we see there has been no explosion of mount points,
|
||||
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:
|
||||
.PP
|
||||
|
|
@ -632,7 +632,7 @@ under each user's directory:
|
|||
The following table shows the effect that applying a new propagation type
|
||||
(i.e.,
|
||||
.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,
|
||||
and the columns are the new propagation settings.
|
||||
For reasons of space, "private" is abbreviated as "priv" and
|
||||
|
|
@ -667,9 +667,9 @@ mount \-\-bind A/a B/b
|
|||
.PP
|
||||
Here,
|
||||
.I A
|
||||
is the source mount point,
|
||||
is the source mount,
|
||||
.I B
|
||||
is the destination mount point,
|
||||
is the destination mount,
|
||||
.I a
|
||||
is a subdirectory path under the mount point
|
||||
.IR A ,
|
||||
|
|
@ -679,7 +679,7 @@ is a subdirectory path under the mount point
|
|||
.IR B .
|
||||
The propagation type of the resulting mount,
|
||||
.IR B/b ,
|
||||
depends on the propagation types of the mount points
|
||||
depends on the propagation types of the mounts
|
||||
.IR A
|
||||
and
|
||||
.IR B ,
|
||||
|
|
@ -715,15 +715,15 @@ mount \-\-move A B/b
|
|||
.PP
|
||||
Here,
|
||||
.I A
|
||||
is the source mount point,
|
||||
is the source mount,
|
||||
.I B
|
||||
is the destination mount point, and
|
||||
is the destination mount, and
|
||||
.I b
|
||||
is a subdirectory path under the mount point
|
||||
.IR B .
|
||||
The propagation type of the resulting mount,
|
||||
.IR B/b ,
|
||||
depends on the propagation types of the mount points
|
||||
depends on the propagation types of the mounts
|
||||
.IR A
|
||||
and
|
||||
.IR B ,
|
||||
|
|
@ -747,7 +747,7 @@ For further details, see
|
|||
in the kernel source tree.
|
||||
.\"
|
||||
.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
|
||||
.in +4n
|
||||
.EX
|
||||
|
|
@ -757,7 +757,7 @@ mount device B/b
|
|||
.PP
|
||||
Here,
|
||||
.I B
|
||||
is the destination mount point, and
|
||||
is the destination mount, and
|
||||
.I b
|
||||
is a subdirectory path under the mount point
|
||||
.IR B .
|
||||
|
|
@ -768,7 +768,7 @@ where the propagation type of the source mount
|
|||
is considered always to be private.
|
||||
.\"
|
||||
.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
|
||||
.in +4n
|
||||
.EX
|
||||
|
|
@ -778,7 +778,7 @@ unmount A
|
|||
.PP
|
||||
Here,
|
||||
.I A
|
||||
is a mount point on
|
||||
is a mount on
|
||||
.IR B/b ,
|
||||
where
|
||||
.I B
|
||||
|
|
@ -871,7 +871,7 @@ onto
|
|||
.EE
|
||||
.in
|
||||
.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
|
||||
.IR /tmp/etc
|
||||
a slave of
|
||||
|
|
@ -896,7 +896,7 @@ Then we bind mount
|
|||
.IR /tmp/etc
|
||||
onto
|
||||
.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
|
||||
.IR /mnt/tmp/etc
|
||||
a slave of
|
||||
|
|
@ -965,9 +965,9 @@ Mount namespaces first appeared in Linux 2.4.19.
|
|||
Namespaces are a Linux-specific feature.
|
||||
.\"
|
||||
.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.
|
||||
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
|
||||
.BR MS_SHARED ,
|
||||
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 .
|
||||
.PP
|
||||
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_SHARED
|
||||
is typically more useful.
|
||||
For this reason,
|
||||
.BR systemd (1)
|
||||
automatically remounts all mount points as
|
||||
automatically remounts all mounts as
|
||||
.BR MS_SHARED
|
||||
on system startup.
|
||||
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
|
||||
.BR unshare (1)
|
||||
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,
|
||||
.BR unshare (1)
|
||||
(since
|
||||
.IR util\-linux
|
||||
version 2.27) in turn reverses the step performed by
|
||||
.BR systemd (1),
|
||||
by making all mount points private in the new namespace.
|
||||
by making all mounts private in the new namespace.
|
||||
That is,
|
||||
.BR unshare (1)
|
||||
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
|
||||
.BR unshare (1)).
|
||||
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
|
||||
or
|
||||
.BR MS_PRIVATE ,
|
||||
|
|
@ -1048,9 +1048,9 @@ Note the following points with respect to mount namespaces:
|
|||
.IP * 3
|
||||
Each mount namespace has an owner user namespace.
|
||||
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.
|
||||
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,
|
||||
then the new mount namespace is considered
|
||||
.IR "less privileged" .
|
||||
|
|
@ -1139,7 +1139,7 @@ In the new mount namespace,
|
|||
the propagation type of all mounts is set to private.
|
||||
We then create a shared bind mount at
|
||||
.IR /mnt ,
|
||||
and a small hierarchy of mount points underneath that mount point.
|
||||
and a small hierarchy of mounts underneath that mount.
|
||||
.IP
|
||||
.in +4n
|
||||
.EX
|
||||
|
|
@ -1162,7 +1162,7 @@ ns1# \fBgrep /mnt /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
|
|||
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 mount points rooted at
|
||||
check the state of the propagated mounts rooted at
|
||||
.IR /mnt .
|
||||
.IP
|
||||
.in +4n
|
||||
|
|
@ -1176,7 +1176,7 @@ ns2# \fBgrep /mnt /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
|
|||
.EE
|
||||
.in
|
||||
.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
|
||||
has been reduced to slave, as explained near the start of this subsection.
|
||||
This means that submount events will propagate from the master
|
||||
|
|
|
|||
Loading…
Reference in New Issue