1MOUNT_NAMESPACES(7) Linux Programmer's Manual MOUNT_NAMESPACES(7)
2
6 mount_namespaces - overview of Linux mount namespaces
7
9 For an overview of namespaces, see namespaces(7).
10 Mount namespaces provide isolation of the list of mount points seen by
12 the processes in each namespace instance. Thus, the processes in each
13 of the mount namespace instances will see distinct single-directory
14 hierarchies.
15 The views provided by the /proc/[pid]/mounts, /proc/[pid]/mountinfo,
17 and /proc/[pid]/mountstats files (all described in proc(5)) correspond
18 to the mount namespace in which the process with the PID [pid] resides.
19 (All of the processes that reside in the same mount namespace will see
20 the same view in these files.)
21 When a process creates a new mount namespace using clone(2) or
23 unshare(2) with the CLONE_NEWNS flag, the mount point list for the new
24 namespace is a copy of the caller's mount point list. Subsequent modi‐
25 fications to the mount point list (mount(2) and umount(2)) in either
26 mount namespace will not (by default) affect the mount point list seen
27 in the other namespace (but see the following discussion of shared sub‐
28 trees).
29 Restrictions on mount namespaces
31 Note the following points with respect to mount namespaces:
32 * A mount namespace has an owner user namespace. A mount namespace
34 whose owner user namespace is different from the owner user names‐
35 pace of its parent mount namespace is considered a less privileged
36 mount namespace.
37 * When creating a less privileged mount namespace, shared mounts are
39 reduced to slave mounts. (Shared and slave mounts are discussed
40 below.) This ensures that mappings performed in less privileged
41 mount namespaces will not propagate to more privileged mount names‐
42 paces.
43 * Mounts that come as a single unit from more privileged mount are
45 locked together and may not be separated in a less privileged mount
46 namespace. (The unshare(2) CLONE_NEWNS operation brings across all
47 of the mounts from the original mount namespace as a single unit,
48 and recursive mounts that propagate between mount namespaces propa‐
49 gate as a single unit.)
50 * The mount(2) flags MS_RDONLY, MS_NOSUID, MS_NOEXEC, and the "atime"
52 flags (MS_NOATIME, MS_NODIRATIME, MS_RELATIME) settings become
53 locked when propagated from a more privileged to a less privileged
54 mount namespace, and may not be changed in the less privileged mount
55 namespace.
56 * A file or directory that is a mount point in one namespace that is
58 not a mount point in another namespace, may be renamed, unlinked, or
59 removed (rmdir(2)) in the mount namespace in which it is not a mount
60 point (subject to the usual permission checks). Consequently, the
61 mount point is removed in the mount namespace where it was a mount
62 point.
63 Previously (before Linux 3.18), attempting to unlink, rename, or
65 remove a file or directory that was a mount point in another mount
66 namespace would result in the error EBUSY. That behavior had tech‐
67 nical problems of enforcement (e.g., for NFS) and permitted denial-
68 of-service attacks against more privileged users. (i.e., preventing
69 individual files from being updated by bind mounting on top of
70 them).
71
73 After the implementation of mount namespaces was completed, experience
74 showed that the isolation that they provided was, in some cases, too
75 great. For example, in order to make a newly loaded optical disk
76 available in all mount namespaces, a mount operation was required in
77 each namespace. For this use case, and others, the shared subtree fea‐
78 ture was introduced in Linux 2.6.15. This feature allows for auto‐
79 matic, controlled propagation of mount and unmount events between
80 namespaces (or, more precisely, between the members of a peer group
81 that are propagating events to one another).
82 Each mount point is marked (via mount(2)) as having one of the follow‐
84 ing propagation types:
85 MS_SHARED
87 This mount point shares events with members of a peer group.
88 Mount and unmount events immediately under this mount point will
89 propagate to the other mount points that are members of the peer
90 group. Propagation here means that the same mount or unmount
91 will automatically occur under all of the other mount points in
92 the peer group. Conversely, mount and unmount events that take
93 place under peer mount points will propagate to this mount
94 point.
95 MS_PRIVATE
97 This mount point is private; it does not have a peer group.
98 Mount and unmount events do not propagate into or out of this
99 mount point.
100 MS_SLAVE
102 Mount and unmount events propagate into this mount point from a
103 (master) shared peer group. Mount and unmount events under this
104 mount point do not propagate to any peer.
105 Note that a mount point can be the slave of another peer group
107 while at the same time sharing mount and unmount events with a
108 peer group of which it is a member. (More precisely, one peer
109 group can be the slave of another peer group.)
110 MS_UNBINDABLE
112 This is like a private mount, and in addition this mount can't
113 be bind mounted. Attempts to bind mount this mount (mount(2)
114 with the MS_BIND flag) will fail.
115 When a recursive bind mount (mount(2) with the MS_BIND and
117 MS_REC flags) is performed on a directory subtree, any bind
118 mounts within the subtree are automatically pruned (i.e., not
119 replicated) when replicating that subtree to produce the target
120 subtree.
121 For a discussion of the propagation type assigned to a new mount, see
123 NOTES.
124 The propagation type is a per-mount-point setting; some mount points
126 may be marked as shared (with each shared mount point being a member of
127 a distinct peer group), while others are private (or slaved or unbind‐
128 able).
129 Note that a mount's propagation type determines whether mounts and
131 unmounts of mount points immediately under the mount point are propa‐
132 gated. Thus, the propagation type does not affect propagation of
133 events for grandchildren and further removed descendant mount points.
134 What happens if the mount point itself is unmounted is determined by
135 the propagation type that is in effect for the parent of the mount
136 point.
137 Members are added to a peer group when a mount point is marked as
139 shared and either:
140 * the mount point is replicated during the creation of a new mount
142 namespace; or
143 * a new bind mount is created from the mount point.
145 In both of these cases, the new mount point joins the peer group of
147 which the existing mount point is a member.
148 A new peer group is also created when a child mount point is created
150 under an existing mount point that is marked as shared. In this case,
151 the new child mount point is also marked as shared and the resulting
152 peer group consists of all the mount points that are replicated under
153 the peers of parent mount.
154 A mount ceases to be a member of a peer group when either the mount is
156 explicitly unmounted, or when the mount is implicitly unmounted because
157 a mount namespace is removed (because it has no more member processes).
158 The propagation type of the mount points in a mount namespace can be
160 discovered via the "optional fields" exposed in /proc/[pid]/mountinfo.
161 (See proc(5) for details of this file.) The following tags can appear
162 in the optional fields for a record in that file:
163 shared:X
165 This mount point is shared in peer group X. Each peer group has
166 a unique ID that is automatically generated by the kernel, and
167 all mount points in the same peer group will show the same ID.
168 (These IDs are assigned starting from the value 1, and may be
169 recycled when a peer group ceases to have any members.)
170 master:X
172 This mount is a slave to shared peer group X.
173 propagate_from:X (since Linux 2.6.26)
175 This mount is a slave and receives propagation from shared peer
176 group X. This tag will always appear in conjunction with a mas‐
177 ter:X tag. Here, X is the closest dominant peer group under the
178 process's root directory. If X is the immediate master of the
179 mount, or if there is no dominant peer group under the same
180 root, then only the master:X field is present and not the propa‐
181 gate_from:X field. For further details, see below.
182 unbindable
184 This is an unbindable mount.
185 If none of the above tags is present, then this is a private mount.
187 MS_SHARED and MS_PRIVATE example
189 Suppose that on a terminal in the initial mount namespace, we mark one
190 mount point as shared and another as private, and then view the mounts
191 in /proc/self/mountinfo:
192 sh1# mount --make-shared /mntS
194 sh1# mount --make-private /mntP
195 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
196 77 61 8:17 / /mntS rw,relatime shared:1
197 83 61 8:15 / /mntP rw,relatime
198 From the /proc/self/mountinfo output, we see that /mntS is a shared
200 mount in peer group 1, and that /mntP has no optional tags, indicating
201 that it is a private mount. The first two fields in each record in
202 this file are the unique ID for this mount, and the mount ID of the
203 parent mount. We can further inspect this file to see that the parent
204 mount point of /mntS and /mntP is the root directory, /, which is
205 mounted as private:
206 sh1# cat /proc/self/mountinfo | awk '$1 == 61' | sed 's/ - .*//'
208 61 0 8:2 / / rw,relatime
209 On a second terminal, we create a new mount namespace where we run a
211 second shell and inspect the mounts:
212 $ PS1='sh2# ' sudo unshare -m --propagation unchanged sh
214 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
215 222 145 8:17 / /mntS rw,relatime shared:1
216 225 145 8:15 / /mntP rw,relatime
217 The new mount namespace received a copy of the initial mount names‐
219 pace's mount points. These new mount points maintain the same propaga‐
220 tion types, but have unique mount IDs. (The --propagation unchanged
221 option prevents unshare(1) from marking all mounts as private when cre‐
222 ating a new mount namespace, which it does by default.)
223 In the second terminal, we then create submounts under each of /mntS
225 and /mntP and inspect the set-up:
226 sh2# mkdir /mntS/a
228 sh2# mount /dev/sdb6 /mntS/a
229 sh2# mkdir /mntP/b
230 sh2# mount /dev/sdb7 /mntP/b
231 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
232 222 145 8:17 / /mntS rw,relatime shared:1
233 225 145 8:15 / /mntP rw,relatime
234 178 222 8:22 / /mntS/a rw,relatime shared:2
235 230 225 8:23 / /mntP/b rw,relatime
236 From the above, it can be seen that /mntS/a was created as shared
238 (inheriting this setting from its parent mount) and /mntP/b was created
239 as a private mount.
240 Returning to the first terminal and inspecting the set-up, we see that
242 the new mount created under the shared mount point /mntS propagated to
243 its peer mount (in the initial mount namespace), but the new mount cre‐
244 ated under the private mount point /mntP did not propagate:
245 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
247 77 61 8:17 / /mntS rw,relatime shared:1
248 83 61 8:15 / /mntP rw,relatime
249 179 77 8:22 / /mntS/a rw,relatime shared:2
250 MS_SLAVE example
252 Making a mount point a slave allows it to receive propagated mount and
253 unmount events from a master shared peer group, while preventing it
254 from propagating events to that master. This is useful if we want to
255 (say) receive a mount event when an optical disk is mounted in the mas‐
256 ter shared peer group (in another mount namespace), but want to prevent
257 mount and unmount events under the slave mount from having side effects
258 in other namespaces.
259 We can demonstrate the effect of slaving by first marking two mount
261 points as shared in the initial mount namespace:
262 sh1# mount --make-shared /mntX
264 sh1# mount --make-shared /mntY
265 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
266 132 83 8:23 / /mntX rw,relatime shared:1
267 133 83 8:22 / /mntY rw,relatime shared:2
268 On a second terminal, we create a new mount namespace and inspect the
270 mount points:
271 sh2# unshare -m --propagation unchanged sh
273 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
274 168 167 8:23 / /mntX rw,relatime shared:1
275 169 167 8:22 / /mntY rw,relatime shared:2
276 In the new mount namespace, we then mark one of the mount points as a
278 slave:
279 sh2# mount --make-slave /mntY
281 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
282 168 167 8:23 / /mntX rw,relatime shared:1
283 169 167 8:22 / /mntY rw,relatime master:2
284 From the above output, we see that /mntY is now a slave mount that is
286 receiving propagation events from the shared peer group with the ID 2.
287 Continuing in the new namespace, we create submounts under each of
289 /mntX and /mntY:
290 sh2# mkdir /mntX/a
292 sh2# mount /dev/sda3 /mntX/a
293 sh2# mkdir /mntY/b
294 sh2# mount /dev/sda5 /mntY/b
295 When we inspect the state of the mount points in the new mount names‐
297 pace, we see that /mntX/a was created as a new shared mount (inheriting
298 the "shared" setting from its parent mount) and /mntY/b was created as
299 a private mount:
300 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
302 168 167 8:23 / /mntX rw,relatime shared:1
303 169 167 8:22 / /mntY rw,relatime master:2
304 173 168 8:3 / /mntX/a rw,relatime shared:3
305 175 169 8:5 / /mntY/b rw,relatime
306 Returning to the first terminal (in the initial mount namespace), we
308 see that the mount /mntX/a propagated to the peer (the shared /mntX),
309 but the mount /mntY/b was not propagated:
310 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
312 132 83 8:23 / /mntX rw,relatime shared:1
313 133 83 8:22 / /mntY rw,relatime shared:2
314 174 132 8:3 / /mntX/a rw,relatime shared:3
315 Now we create a new mount point under /mntY in the first shell:
317 sh1# mkdir /mntY/c
319 sh1# mount /dev/sda1 /mntY/c
320 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
321 132 83 8:23 / /mntX rw,relatime shared:1
322 133 83 8:22 / /mntY rw,relatime shared:2
323 174 132 8:3 / /mntX/a rw,relatime shared:3
324 178 133 8:1 / /mntY/c rw,relatime shared:4
325 When we examine the mount points in the second mount namespace, we see
327 that in this case the new mount has been propagated to the slave mount
328 point, and that the new mount is itself a slave mount (to peer group
329 4):
330 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
332 168 167 8:23 / /mntX rw,relatime shared:1
333 169 167 8:22 / /mntY rw,relatime master:2
334 173 168 8:3 / /mntX/a rw,relatime shared:3
335 175 169 8:5 / /mntY/b rw,relatime
336 179 169 8:1 / /mntY/c rw,relatime master:4
337 MS_UNBINDABLE example
339 One of the primary purposes of unbindable mounts is to avoid the "mount
340 point explosion" problem when repeatedly performing bind mounts of a
341 higher-level subtree at a lower-level mount point. The problem is
342 illustrated by the following shell session.
343 Suppose we have a system with the following mount points:
345 # mount | awk '{print $1, $2, $3}'
347 /dev/sda1 on /
348 /dev/sdb6 on /mntX
349 /dev/sdb7 on /mntY
350 Suppose furthermore that we wish to recursively bind mount the root
352 directory under several users' home directories. We do this for the
353 first user, and inspect the mount points:
354 # mount --rbind / /home/cecilia/
356 # mount | awk '{print $1, $2, $3}'
357 /dev/sda1 on /
358 /dev/sdb6 on /mntX
359 /dev/sdb7 on /mntY
360 /dev/sda1 on /home/cecilia
361 /dev/sdb6 on /home/cecilia/mntX
362 /dev/sdb7 on /home/cecilia/mntY
363 When we repeat this operation for the second user, we start to see the
365 explosion problem:
366 # mount --rbind / /home/henry
368 # mount | awk '{print $1, $2, $3}'
369 /dev/sda1 on /
370 /dev/sdb6 on /mntX
371 /dev/sdb7 on /mntY
372 /dev/sda1 on /home/cecilia
373 /dev/sdb6 on /home/cecilia/mntX
374 /dev/sdb7 on /home/cecilia/mntY
375 /dev/sda1 on /home/henry
376 /dev/sdb6 on /home/henry/mntX
377 /dev/sdb7 on /home/henry/mntY
378 /dev/sda1 on /home/henry/home/cecilia
379 /dev/sdb6 on /home/henry/home/cecilia/mntX
380 /dev/sdb7 on /home/henry/home/cecilia/mntY
381 Under /home/henry, we have not only recursively added the /mntX and
383 /mntY mounts, but also the recursive mounts of those directories under
384 /home/cecilia that were created in the previous step. Upon repeating
385 the step for a third user, it becomes obvious that the explosion is
386 exponential in nature:
387 # mount --rbind / /home/otto
389 # mount | awk '{print $1, $2, $3}'
390 /dev/sda1 on /
391 /dev/sdb6 on /mntX
392 /dev/sdb7 on /mntY
393 /dev/sda1 on /home/cecilia
394 /dev/sdb6 on /home/cecilia/mntX
395 /dev/sdb7 on /home/cecilia/mntY
396 /dev/sda1 on /home/henry
397 /dev/sdb6 on /home/henry/mntX
398 /dev/sdb7 on /home/henry/mntY
399 /dev/sda1 on /home/henry/home/cecilia
400 /dev/sdb6 on /home/henry/home/cecilia/mntX
401 /dev/sdb7 on /home/henry/home/cecilia/mntY
402 /dev/sda1 on /home/otto
403 /dev/sdb6 on /home/otto/mntX
404 /dev/sdb7 on /home/otto/mntY
405 /dev/sda1 on /home/otto/home/cecilia
406 /dev/sdb6 on /home/otto/home/cecilia/mntX
407 /dev/sdb7 on /home/otto/home/cecilia/mntY
408 /dev/sda1 on /home/otto/home/henry
409 /dev/sdb6 on /home/otto/home/henry/mntX
410 /dev/sdb7 on /home/otto/home/henry/mntY
411 /dev/sda1 on /home/otto/home/henry/home/cecilia
412 /dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
413 /dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY
414 The mount explosion problem in the above scenario can be avoided by
416 making each of the new mounts unbindable. The effect of doing this is
417 that recursive mounts of the root directory will not replicate the
418 unbindable mounts. We make such a mount for the first user:
419 # mount --rbind --make-unbindable / /home/cecilia
421 Before going further, we show that unbindable mounts are indeed unbind‐
423 able:
424 # mkdir /mntZ
426 # mount --bind /home/cecilia /mntZ
427 mount: wrong fs type, bad option, bad superblock on /home/cecilia,
428 missing codepage or helper program, or other error
429 In some cases useful info is found in syslog - try
431 dmesg | tail or so.
432 Now we create unbindable recursive bind mounts for the other two users:
434 # mount --rbind --make-unbindable / /home/henry
436 # mount --rbind --make-unbindable / /home/otto
437 Upon examining the list of mount points, we see there has been no
439 explosion of mount points, because the unbindable mounts were not
440 replicated under each user's directory:
441 # mount | awk '{print $1, $2, $3}'
443 /dev/sda1 on /
444 /dev/sdb6 on /mntX
445 /dev/sdb7 on /mntY
446 /dev/sda1 on /home/cecilia
447 /dev/sdb6 on /home/cecilia/mntX
448 /dev/sdb7 on /home/cecilia/mntY
449 /dev/sda1 on /home/henry
450 /dev/sdb6 on /home/henry/mntX
451 /dev/sdb7 on /home/henry/mntY
452 /dev/sda1 on /home/otto
453 /dev/sdb6 on /home/otto/mntX
454 /dev/sdb7 on /home/otto/mntY
455 Propagation type transitions
457 The following table shows the effect that applying a new propagation
458 type (i.e., mount --make-xxxx) has on the existing propagation type of
459 a mount point. The rows correspond to existing propagation types, and
460 the columns are the new propagation settings. For reasons of space,
461 "private" is abbreviated as "priv" and "unbindable" as "unbind".
462 make-shared make-slave make-priv make-unbind
464 shared shared slave/priv [1] priv unbind
465 slave slave+shared slave [2] priv unbind
466 slave+shared slave+shared slave priv unbind
467 private shared priv [2] priv unbind
468 unbindable shared unbind [2] priv unbind
469 Note the following details to the table:
471 [1] If a shared mount is the only mount in its peer group, making it a
473 slave automatically makes it private.
474 [2] Slaving a nonshared mount has no effect on the mount.
476 Bind (MS_BIND) semantics
478 Suppose that the following command is performed:
479 mount --bind A/a B/b
481 Here, A is the source mount point, B is the destination mount point, a
483 is a subdirectory path under the mount point A, and b is a subdirectory
484 path under the mount point B. The propagation type of the resulting
485 mount, B/b, depends on the propagation types of the mount points A and
486 B, and is summarized in the following table.
487 source(A)
489 shared private slave unbind
490 ───────────────────────────────────────────────────────────────
491 dest(B) shared | shared shared slave+shared invalid
492 nonshared | shared private slave invalid
493 Note that a recursive bind of a subtree follows the same semantics as
495 for a bind operation on each mount in the subtree. (Unbindable mounts
496 are automatically pruned at the target mount point.)
497 For further details, see Documentation/filesystems/sharedsubtree.txt in
499 the kernel source tree.
500 Move (MS_MOVE) semantics
502 Suppose that the following command is performed:
503 mount --move A B/b
505 Here, A is the source mount point, B is the destination mount point,
507 and b is a subdirectory path under the mount point B. The propagation
508 type of the resulting mount, B/b, depends on the propagation types of
509 the mount points A and B, and is summarized in the following table.
510 source(A)
512 shared private slave unbind
513 ──────────────────────────────────────────────────────────────────
514 dest(B) shared | shared shared slave+shared invalid
515 nonshared | shared private slave unbindable
516 Note: moving a mount that resides under a shared mount is invalid.
518 For further details, see Documentation/filesystems/sharedsubtree.txt in
520 the kernel source tree.
521 Mount semantics
523 Suppose that we use the following command to create a mount point:
524 mount device B/b
526 Here, B is the destination mount point, and b is a subdirectory path
528 under the mount point B. The propagation type of the resulting mount,
529 B/b, follows the same rules as for a bind mount, where the propagation
530 type of the source mount is considered always to be private.
531 Unmount semantics
533 Suppose that we use the following command to tear down a mount point:
534 unmount A
536 Here, A is a mount point on B/b, where B is the parent mount and b is a
538 subdirectory path under the mount point B. If B is shared, then all
539 most-recently-mounted mounts at b on mounts that receive propagation
540 from mount B and do not have submounts under them are unmounted.
541 The /proc/[pid]/mountinfo propagate_from tag
543 The propagate_from:X tag is shown in the optional fields of a
544 /proc/[pid]/mountinfo record in cases where a process can't see a
545 slave's immediate master (i.e., the pathname of the master is not
546 reachable from the filesystem root directory) and so cannot determine
547 the chain of propagation between the mounts it can see.
548 In the following example, we first create a two-link master-slave chain
550 between the mounts /mnt, /tmp/etc, and /mnt/tmp/etc. Then the
551 chroot(1) command is used to make the /tmp/etc mount point unreachable
552 from the root directory, creating a situation where the master of
553 /mnt/tmp/etc is not reachable from the (new) root directory of the
554 process.
555 First, we bind mount the root directory onto /mnt and then bind mount
557 /proc at /mnt/proc so that after the later chroot(1) the proc(5)
558 filesystem remains visible at the correct location in the chroot-ed
559 environment.
560 # mkdir -p /mnt/proc
562 # mount --bind / /mnt
563 # mount --bind /proc /mnt/proc
564 Next, we ensure that the /mnt mount is a shared mount in a new peer
566 group (with no peers):
567 # mount --make-private /mnt # Isolate from any previous peer group
569 # mount --make-shared /mnt
570 # cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
571 239 61 8:2 / /mnt ... shared:102
572 248 239 0:4 / /mnt/proc ... shared:5
573 Next, we bind mount /mnt/etc onto /tmp/etc:
575 # mkdir -p /tmp/etc
577 # mount --bind /mnt/etc /tmp/etc
578 # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
579 239 61 8:2 / /mnt ... shared:102
580 248 239 0:4 / /mnt/proc ... shared:5
581 267 40 8:2 /etc /tmp/etc ... shared:102
582 Initially, these two mount points are in the same peer group, but we
584 then make the /tmp/etc a slave of /mnt/etc, and then make /tmp/etc
585 shared as well, so that it can propagate events to the next slave in
586 the chain:
587 # mount --make-slave /tmp/etc
589 # mount --make-shared /tmp/etc
590 # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
591 239 61 8:2 / /mnt ... shared:102
592 248 239 0:4 / /mnt/proc ... shared:5
593 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
594 Then we bind mount /tmp/etc onto /mnt/tmp/etc. Again, the two mount
596 points are initially in the same peer group, but we then make
597 /mnt/tmp/etc a slave of /tmp/etc:
598 # mkdir -p /mnt/tmp/etc
600 # mount --bind /tmp/etc /mnt/tmp/etc
601 # mount --make-slave /mnt/tmp/etc
602 # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
603 239 61 8:2 / /mnt ... shared:102
604 248 239 0:4 / /mnt/proc ... shared:5
605 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
606 273 239 8:2 /etc /mnt/tmp/etc ... master:105
607 From the above, we see that /mnt is the master of the slave /tmp/etc,
609 which in turn is the master of the slave /mnt/tmp/etc.
610 We then chroot(1) to the /mnt directory, which renders the mount with
612 ID 267 unreachable from the (new) root directory:
613 # chroot /mnt
615 When we examine the state of the mounts inside the chroot-ed environ‐
617 ment, we see the following:
618 # cat /proc/self/mountinfo | sed 's/ - .*//'
620 239 61 8:2 / / ... shared:102
621 248 239 0:4 / /proc ... shared:5
622 273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102
623 Above, we see that the mount with ID 273 is a slave whose master is the
625 peer group 105. The mount point for that master is unreachable, and so
626 a propagate_from tag is displayed, indicating that the closest dominant
627 peer group (i.e., the nearest reachable mount in the slave chain) is
628 the peer group with the ID 102 (corresponding to the /mnt mount point
629 before the chroot(1) was performed.
630
632 Mount namespaces first appeared in Linux 2.4.19.
633
635 Namespaces are a Linux-specific feature.
636
638 The propagation type assigned to a new mount point depends on the prop‐
639 agation type of the parent mount. If the mount point has a parent
640 (i.e., it is a non-root mount point) and the propagation type of the
641 parent is MS_SHARED, then the propagation type of the new mount is also
642 MS_SHARED. Otherwise, the propagation type of the new mount is MS_PRI‐
643 VATE.
644 Notwithstanding the fact that the default propagation type for new
646 mount points is in many cases MS_PRIVATE, MS_SHARED is typically more
647 useful. For this reason, systemd(1) automatically remounts all mount
648 points as MS_SHARED on system startup. Thus, on most modern systems,
649 the default propagation type is in practice MS_SHARED.
650 Since, when one uses unshare(1) to create a mount namespace, the goal
652 is commonly to provide full isolation of the mount points in the new
653 namespace, unshare(1) (since util-linux version 2.27) in turn reverses
654 the step performed by systemd(1), by making all mount points private in
655 the new namespace. That is, unshare(1) performs the equivalent of the
656 following in the new mount namespace:
657 mount --make-rprivate /
659 To prevent this, one can use the --propagation unchanged option to
661 unshare(1).
662 For a discussion of propagation types when moving mounts (MS_MOVE) and
664 creating bind mounts (MS_BIND), see Documentation/filesystems/shared‐
665 subtree.txt.
666
668 unshare(1), clone(2), mount(2), pivot_root(2), setns(2), umount(2),
669 unshare(2), proc(5), namespaces(7), user_namespaces(7), findmnt(8),
670 pivot_root(8)
671 Documentation/filesystems/sharedsubtree.txt in the kernel source tree.
673
675 This page is part of release 5.02 of the Linux man-pages project. A
676 description of the project, information about reporting bugs, and the
677 latest version of this page, can be found at
678 https://www.kernel.org/doc/man-pages/.
679Linux 2019-08-02 MOUNT_NAMESPACES(7)