| blob | 826faf00a3a79e377001e7751b974294e70da4fe |
1 .\" Copyright (c) 2016, 2019, 2021 by Michael Kerrisk <mtk.manpages@gmail.com>
2 .\"
3 .\" %%%LICENSE_START(VERBATIM)
4 .\" Permission is granted to make and distribute verbatim copies of this
5 .\" manual provided the copyright notice and this permission notice are
6 .\" preserved on all copies.
7 .\"
8 .\" Permission is granted to copy and distribute modified versions of this
9 .\" manual under the conditions for verbatim copying, provided that the
10 .\" entire resulting derived work is distributed under the terms of a
11 .\" permission notice identical to this one.
12 .\"
13 .\" Since the Linux kernel and libraries are constantly changing, this
14 .\" manual page may be incorrect or out-of-date. The author(s) assume no
15 .\" responsibility for errors or omissions, or for damages resulting from
16 .\" the use of the information contained herein. The author(s) may not
17 .\" have taken the same level of care in the production of this manual,
18 .\" which is licensed free of charge, as they might when working
19 .\" professionally.
20 .\"
21 .\" Formatted or processed versions of this manual, if unaccompanied by
22 .\" the source, must acknowledge the copyright and authors of this work.
23 .\" %%%LICENSE_END
24 .\"
25 .\"
26 .TH MOUNT_NAMESPACES 7 2021-03-22 "Linux" "Linux Programmer's Manual"
27 .SH NAME
28 mount_namespaces \- overview of Linux mount namespaces
29 .SH DESCRIPTION
30 For an overview of namespaces, see
31 .BR namespaces (7).
32 .PP
33 Mount namespaces provide isolation of the list of mounts seen
34 by the processes in each namespace instance.
35 Thus, the processes in each of the mount namespace instances
36 will see distinct single-directory hierarchies.
37 .PP
38 The views provided by the
39 .IR /proc/[pid]/mounts ,
40 .IR /proc/[pid]/mountinfo ,
41 and
42 .IR /proc/[pid]/mountstats
43 files (all described in
44 .BR proc (5))
45 correspond to the mount namespace in which the process with the PID
46 .IR [pid]
47 resides.
48 (All of the processes that reside in the same mount namespace
49 will see the same view in these files.)
50 .PP
51 A new mount namespace is created using either
52 .BR clone (2)
53 or
54 .BR unshare (2)
55 with the
56 .BR CLONE_NEWNS
57 flag.
58 When a new mount namespace is created,
59 its mount list is initialized as follows:
60 .IP * 3
61 If the namespace is created using
62 .BR clone (2),
63 the mount list of the child's namespace is a copy
64 of the mount list in the parent process's mount namespace.
65 .IP *
66 If the namespace is created using
67 .BR unshare (2),
68 the mount list of the new namespace is a copy of
69 the mount list in the caller's previous mount namespace.
70 .PP
71 Subsequent modifications to the mount list
72 .RB ( mount (2)
73 and
74 .BR umount (2))
75 in either mount namespace will not (by default) affect the
76 mount list seen in the other namespace
77 (but see the following discussion of shared subtrees).
78 .\"
79 .SH SHARED SUBTREES
80 After the implementation of mount namespaces was completed,
81 experience showed that the isolation that they provided was,
82 in some cases, too great.
83 For example, in order to make a newly loaded optical disk
84 available in all mount namespaces,
85 a mount operation was required in each namespace.
86 For this use case, and others,
87 the shared subtree feature was introduced in Linux 2.6.15.
88 This feature allows for automatic, controlled propagation of mount and unmount
89 .I events
90 between namespaces
91 (or, more precisely, between the members of a
92 .IR "peer group"
93 that are propagating events to one another).
94 .PP
95 Each mount is marked (via
96 .BR mount (2))
97 as having one of the following
98 .IR "propagation types" :
99 .TP
100 .BR MS_SHARED
101 This mount shares events with members of a peer group.
102 Mount and unmount events immediately under this mount will propagate
103 to the other mounts that are members of the peer group.
104 .I Propagation
105 here means that the same mount or unmount will automatically occur
106 under all of the other mounts in the peer group.
107 Conversely, mount and unmount events that take place under
108 peer mounts will propagate to this mount.
109 .TP
110 .BR MS_PRIVATE
111 This mount is private; it does not have a peer group.
112 Mount and unmount events do not propagate into or out of this mount.
113 .TP
114 .BR MS_SLAVE
115 Mount and unmount events propagate into this mount from
116 a (master) shared peer group.
117 Mount and unmount events under this mount do not propagate to any peer.
118 .IP
119 Note that a mount can be the slave of another peer group
120 while at the same time sharing mount and unmount events
121 with a peer group of which it is a member.
122 (More precisely, one peer group can be the slave of another peer group.)
123 .TP
124 .BR MS_UNBINDABLE
125 This is like a private mount,
126 and in addition this mount can't be bind mounted.
127 Attempts to bind mount this mount
128 .RB ( mount (2)
129 with the
130 .BR MS_BIND
131 flag) will fail.
132 .IP
133 When a recursive bind mount
134 .RB ( mount (2)
135 with the
136 .BR MS_BIND
137 and
138 .BR MS_REC
139 flags) is performed on a directory subtree,
140 any bind mounts within the subtree are automatically pruned
141 (i.e., not replicated)
142 when replicating that subtree to produce the target subtree.
143 .PP
144 For a discussion of the propagation type assigned to a new mount,
145 see NOTES.
146 .PP
147 The propagation type is a per-mount-point setting;
148 some mounts may be marked as shared
149 (with each shared mount being a member of a distinct peer group),
150 while others are private
151 (or slaved or unbindable).
152 .PP
153 Note that a mount's propagation type determines whether
154 mounts and unmounts of mounts
155 .I "immediately under"
156 the mount are propagated.
157 Thus, the propagation type does not affect propagation of events for
158 grandchildren and further removed descendant mounts.
159 What happens if the mount itself is unmounted is determined by
160 the propagation type that is in effect for the
161 .I parent
162 of the mount.
163 .PP
164 Members are added to a
165 .IR "peer group"
166 when a mount is marked as shared and either:
167 .IP * 3
168 the mount is replicated during the creation of a new mount namespace; or
169 .IP *
170 a new bind mount is created from the mount.
171 .PP
172 In both of these cases, the new mount joins the peer group
173 of which the existing mount is a member.
174 .PP
175 A new peer group is also created when a child mount is created under
176 an existing mount that is marked as shared.
177 In this case, the new child mount is also marked as shared and
178 the resulting peer group consists of all the mounts
179 that are replicated under the peers of parent mount.
180 .PP
181 A mount ceases to be a member of a peer group when either
182 the mount is explicitly unmounted,
183 or when the mount is implicitly unmounted because a mount namespace is removed
184 (because it has no more member processes).
185 .PP
186 The propagation type of the mounts in a mount namespace
187 can be discovered via the "optional fields" exposed in
188 .IR /proc/[pid]/mountinfo .
189 (See
190 .BR proc (5)
191 for details of this file.)
192 The following tags can appear in the optional fields
193 for a record in that file:
194 .TP
195 .I shared:X
196 This mount is shared in peer group
197 .IR X .
198 Each peer group has a unique ID that is automatically
199 generated by the kernel,
200 and all mounts in the same peer group will show the same ID.
201 (These IDs are assigned starting from the value 1,
202 and may be recycled when a peer group ceases to have any members.)
203 .TP
204 .I master:X
205 This mount is a slave to shared peer group
206 .IR X .
207 .TP
208 .IR propagate_from:X " (since Linux 2.6.26)"
209 .\" commit 97e7e0f71d6d948c25f11f0a33878d9356d9579e
210 This mount is a slave and receives propagation from shared peer group
211 .IR X .
212 This tag will always appear in conjunction with a
213 .IR master:X
214 tag.
215 Here,
216 .IR X
217 is the closest dominant peer group under the process's root directory.
218 If
219 .IR X
220 is the immediate master of the mount,
221 or if there is no dominant peer group under the same root,
222 then only the
223 .IR master:X
224 field is present and not the
225 .IR propagate_from:X
226 field.
227 For further details, see below.
228 .TP
229 .IR unbindable
230 This is an unbindable mount.
231 .PP
232 If none of the above tags is present, then this is a private mount.
233 .SS MS_SHARED and MS_PRIVATE example
234 Suppose that on a terminal in the initial mount namespace,
235 we mark one mount as shared and another as private,
236 and then view the mounts in
237 .IR /proc/self/mountinfo :
238 .PP
239 .in +4n
240 .EX
241 sh1# \fBmount \-\-make\-shared /mntS\fP
242 sh1# \fBmount \-\-make\-private /mntP\fP
243 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
244 77 61 8:17 / /mntS rw,relatime shared:1
245 83 61 8:15 / /mntP rw,relatime
246 .EE
247 .in
248 .PP
249 From the
250 .IR /proc/self/mountinfo
251 output, we see that
252 .IR /mntS
253 is a shared mount in peer group 1, and that
254 .IR /mntP
255 has no optional tags, indicating that it is a private mount.
256 The first two fields in each record in this file are the unique
257 ID for this mount, and the mount ID of the parent mount.
258 We can further inspect this file to see that the parent mount of
259 .IR /mntS
260 and
261 .IR /mntP
262 is the root directory,
263 .IR / ,
264 which is mounted as private:
265 .PP
266 .in +4n
267 .EX
268 sh1# \fBcat /proc/self/mountinfo | awk \(aq$1 == 61\(aq | sed \(aqs/ \- .*//\(aq\fP
269 61 0 8:2 / / rw,relatime
270 .EE
271 .in
272 .PP
273 On a second terminal,
274 we create a new mount namespace where we run a second shell
275 and inspect the mounts:
276 .PP
277 .in +4n
278 .EX
279 $ \fBPS1=\(aqsh2# \(aq sudo unshare \-m \-\-propagation unchanged sh\fP
280 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
281 222 145 8:17 / /mntS rw,relatime shared:1
282 225 145 8:15 / /mntP rw,relatime
283 .EE
284 .in
285 .PP
286 The new mount namespace received a copy of the initial mount namespace's
287 mounts.
288 These new mounts maintain the same propagation types,
289 but have unique mount IDs.
290 (The
291 .IR \-\-propagation\ unchanged
292 option prevents
293 .BR unshare (1)
294 from marking all mounts as private when creating a new mount namespace,
295 .\" Since util-linux 2.27
296 which it does by default.)
297 .PP
298 In the second terminal, we then create submounts under each of
299 .IR /mntS
300 and
301 .IR /mntP
302 and inspect the set-up:
303 .PP
304 .in +4n
305 .EX
306 sh2# \fBmkdir /mntS/a\fP
307 sh2# \fBmount /dev/sdb6 /mntS/a\fP
308 sh2# \fBmkdir /mntP/b\fP
309 sh2# \fBmount /dev/sdb7 /mntP/b\fP
310 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
311 222 145 8:17 / /mntS rw,relatime shared:1
312 225 145 8:15 / /mntP rw,relatime
313 178 222 8:22 / /mntS/a rw,relatime shared:2
314 230 225 8:23 / /mntP/b rw,relatime
315 .EE
316 .in
317 .PP
318 From the above, it can be seen that
319 .IR /mntS/a
320 was created as shared (inheriting this setting from its parent mount) and
321 .IR /mntP/b
322 was created as a private mount.
323 .PP
324 Returning to the first terminal and inspecting the set-up,
325 we see that the new mount created under the shared mount
326 .IR /mntS
327 propagated to its peer mount (in the initial mount namespace),
328 but the new mount created under the private mount
329 .IR /mntP
330 did not propagate:
331 .PP
332 .in +4n
333 .EX
334 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
335 77 61 8:17 / /mntS rw,relatime shared:1
336 83 61 8:15 / /mntP rw,relatime
337 179 77 8:22 / /mntS/a rw,relatime shared:2
338 .EE
339 .in
340 .\"
341 .SS MS_SLAVE example
342 Making a mount a slave allows it to receive propagated
343 mount and unmount events from a master shared peer group,
344 while preventing it from propagating events to that master.
345 This is useful if we want to (say) receive a mount event when
346 an optical disk is mounted in the master shared peer group
347 (in another mount namespace),
348 but want to prevent mount and unmount events under the slave mount
349 from having side effects in other namespaces.
350 .PP
351 We can demonstrate the effect of slaving by first marking
352 two mounts as shared in the initial mount namespace:
353 .PP
354 .in +4n
355 .EX
356 sh1# \fBmount \-\-make\-shared /mntX\fP
357 sh1# \fBmount \-\-make\-shared /mntY\fP
358 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
359 132 83 8:23 / /mntX rw,relatime shared:1
360 133 83 8:22 / /mntY rw,relatime shared:2
361 .EE
362 .in
363 .PP
364 On a second terminal,
365 we create a new mount namespace and inspect the mounts:
366 .PP
367 .in +4n
368 .EX
369 sh2# \fBunshare \-m \-\-propagation unchanged sh\fP
370 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
371 168 167 8:23 / /mntX rw,relatime shared:1
372 169 167 8:22 / /mntY rw,relatime shared:2
373 .EE
374 .in
375 .PP
376 In the new mount namespace, we then mark one of the mounts as a slave:
377 .PP
378 .in +4n
379 .EX
380 sh2# \fBmount \-\-make\-slave /mntY\fP
381 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
382 168 167 8:23 / /mntX rw,relatime shared:1
383 169 167 8:22 / /mntY rw,relatime master:2
384 .EE
385 .in
386 .PP
387 From the above output, we see that
388 .IR /mntY
389 is now a slave mount that is receiving propagation events from
390 the shared peer group with the ID 2.
391 .PP
392 Continuing in the new namespace, we create submounts under each of
393 .IR /mntX
394 and
395 .IR /mntY :
396 .PP
397 .in +4n
398 .EX
399 sh2# \fBmkdir /mntX/a\fP
400 sh2# \fBmount /dev/sda3 /mntX/a\fP
401 sh2# \fBmkdir /mntY/b\fP
402 sh2# \fBmount /dev/sda5 /mntY/b\fP
403 .EE
404 .in
405 .PP
406 When we inspect the state of the mounts in the new mount namespace,
407 we see that
408 .IR /mntX/a
409 was created as a new shared mount
410 (inheriting the "shared" setting from its parent mount) and
411 .IR /mntY/b
412 was created as a private mount:
413 .PP
414 .in +4n
415 .EX
416 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
417 168 167 8:23 / /mntX rw,relatime shared:1
418 169 167 8:22 / /mntY rw,relatime master:2
419 173 168 8:3 / /mntX/a rw,relatime shared:3
420 175 169 8:5 / /mntY/b rw,relatime
421 .EE
422 .in
423 .PP
424 Returning to the first terminal (in the initial mount namespace),
425 we see that the mount
426 .IR /mntX/a
427 propagated to the peer (the shared
428 .IR /mntX ),
429 but the mount
430 .IR /mntY/b
431 was not propagated:
432 .PP
433 .in +4n
434 .EX
435 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
436 132 83 8:23 / /mntX rw,relatime shared:1
437 133 83 8:22 / /mntY rw,relatime shared:2
438 174 132 8:3 / /mntX/a rw,relatime shared:3
439 .EE
440 .in
441 .PP
442 Now we create a new mount under
443 .IR /mntY
444 in the first shell:
445 .PP
446 .in +4n
447 .EX
448 sh1# \fBmkdir /mntY/c\fP
449 sh1# \fBmount /dev/sda1 /mntY/c\fP
450 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
451 132 83 8:23 / /mntX rw,relatime shared:1
452 133 83 8:22 / /mntY rw,relatime shared:2
453 174 132 8:3 / /mntX/a rw,relatime shared:3
454 178 133 8:1 / /mntY/c rw,relatime shared:4
455 .EE
456 .in
457 .PP
458 When we examine the mounts in the second mount namespace,
459 we see that in this case the new mount has been propagated
460 to the slave mount,
461 and that the new mount is itself a slave mount (to peer group 4):
462 .PP
463 .in +4n
464 .EX
465 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
466 168 167 8:23 / /mntX rw,relatime shared:1
467 169 167 8:22 / /mntY rw,relatime master:2
468 173 168 8:3 / /mntX/a rw,relatime shared:3
469 175 169 8:5 / /mntY/b rw,relatime
470 179 169 8:1 / /mntY/c rw,relatime master:4
471 .EE
472 .in
473 .\"
474 .SS MS_UNBINDABLE example
475 One of the primary purposes of unbindable mounts is to avoid
476 the "mount explosion" problem when repeatedly performing bind mounts
477 of a higher-level subtree at a lower-level mount.
478 The problem is illustrated by the following shell session.
479 .PP
480 Suppose we have a system with the following mounts:
481 .PP
482 .in +4n
483 .EX
484 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
485 /dev/sda1 on /
486 /dev/sdb6 on /mntX
487 /dev/sdb7 on /mntY
488 .EE
489 .in
490 .PP
491 Suppose furthermore that we wish to recursively bind mount
492 the root directory under several users' home directories.
493 We do this for the first user, and inspect the mounts:
494 .PP
495 .in +4n
496 .EX
497 # \fBmount \-\-rbind / /home/cecilia/\fP
498 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
499 /dev/sda1 on /
500 /dev/sdb6 on /mntX
501 /dev/sdb7 on /mntY
502 /dev/sda1 on /home/cecilia
503 /dev/sdb6 on /home/cecilia/mntX
504 /dev/sdb7 on /home/cecilia/mntY
505 .EE
506 .in
507 .PP
508 When we repeat this operation for the second user,
509 we start to see the explosion problem:
510 .PP
511 .in +4n
512 .EX
513 # \fBmount \-\-rbind / /home/henry\fP
514 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
515 /dev/sda1 on /
516 /dev/sdb6 on /mntX
517 /dev/sdb7 on /mntY
518 /dev/sda1 on /home/cecilia
519 /dev/sdb6 on /home/cecilia/mntX
520 /dev/sdb7 on /home/cecilia/mntY
521 /dev/sda1 on /home/henry
522 /dev/sdb6 on /home/henry/mntX
523 /dev/sdb7 on /home/henry/mntY
524 /dev/sda1 on /home/henry/home/cecilia
525 /dev/sdb6 on /home/henry/home/cecilia/mntX
526 /dev/sdb7 on /home/henry/home/cecilia/mntY
527 .EE
528 .in
529 .PP
530 Under
531 .IR /home/henry ,
532 we have not only recursively added the
533 .IR /mntX
534 and
535 .IR /mntY
536 mounts, but also the recursive mounts of those directories under
537 .IR /home/cecilia
538 that were created in the previous step.
539 Upon repeating the step for a third user,
540 it becomes obvious that the explosion is exponential in nature:
541 .PP
542 .in +4n
543 .EX
544 # \fBmount \-\-rbind / /home/otto\fP
545 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
546 /dev/sda1 on /
547 /dev/sdb6 on /mntX
548 /dev/sdb7 on /mntY
549 /dev/sda1 on /home/cecilia
550 /dev/sdb6 on /home/cecilia/mntX
551 /dev/sdb7 on /home/cecilia/mntY
552 /dev/sda1 on /home/henry
553 /dev/sdb6 on /home/henry/mntX
554 /dev/sdb7 on /home/henry/mntY
555 /dev/sda1 on /home/henry/home/cecilia
556 /dev/sdb6 on /home/henry/home/cecilia/mntX
557 /dev/sdb7 on /home/henry/home/cecilia/mntY
558 /dev/sda1 on /home/otto
559 /dev/sdb6 on /home/otto/mntX
560 /dev/sdb7 on /home/otto/mntY
561 /dev/sda1 on /home/otto/home/cecilia
562 /dev/sdb6 on /home/otto/home/cecilia/mntX
563 /dev/sdb7 on /home/otto/home/cecilia/mntY
564 /dev/sda1 on /home/otto/home/henry
565 /dev/sdb6 on /home/otto/home/henry/mntX
566 /dev/sdb7 on /home/otto/home/henry/mntY
567 /dev/sda1 on /home/otto/home/henry/home/cecilia
568 /dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
569 /dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY
570 .EE
571 .in
572 .PP
573 The mount explosion problem in the above scenario can be avoided
574 by making each of the new mounts unbindable.
575 The effect of doing this is that recursive mounts of the root
576 directory will not replicate the unbindable mounts.
577 We make such a mount for the first user:
578 .PP
579 .in +4n
580 .EX
581 # \fBmount \-\-rbind \-\-make\-unbindable / /home/cecilia\fP
582 .EE
583 .in
584 .PP
585 Before going further, we show that unbindable mounts are indeed unbindable:
586 .PP
587 .in +4n
588 .EX
589 # \fBmkdir /mntZ\fP
590 # \fBmount \-\-bind /home/cecilia /mntZ\fP
591 mount: wrong fs type, bad option, bad superblock on /home/cecilia,
592 missing codepage or helper program, or other error
594 In some cases useful info is found in syslog \- try
595 dmesg | tail or so.
596 .EE
597 .in
598 .PP
599 Now we create unbindable recursive bind mounts for the other two users:
600 .PP
601 .in +4n
602 .EX
603 # \fBmount \-\-rbind \-\-make\-unbindable / /home/henry\fP
604 # \fBmount \-\-rbind \-\-make\-unbindable / /home/otto\fP
605 .EE
606 .in
607 .PP
608 Upon examining the list of mounts,
609 we see there has been no explosion of mounts,
610 because the unbindable mounts were not replicated
611 under each user's directory:
612 .PP
613 .in +4n
614 .EX
615 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
616 /dev/sda1 on /
617 /dev/sdb6 on /mntX
618 /dev/sdb7 on /mntY
619 /dev/sda1 on /home/cecilia
620 /dev/sdb6 on /home/cecilia/mntX
621 /dev/sdb7 on /home/cecilia/mntY
622 /dev/sda1 on /home/henry
623 /dev/sdb6 on /home/henry/mntX
624 /dev/sdb7 on /home/henry/mntY
625 /dev/sda1 on /home/otto
626 /dev/sdb6 on /home/otto/mntX
627 /dev/sdb7 on /home/otto/mntY
628 .EE
629 .in
630 .\"
631 .SS Propagation type transitions
632 The following table shows the effect that applying a new propagation type
633 (i.e.,
634 .IR "mount \-\-make\-xxxx")
635 has on the existing propagation type of a mount.
636 The rows correspond to existing propagation types,
637 and the columns are the new propagation settings.
638 For reasons of space, "private" is abbreviated as "priv" and
639 "unbindable" as "unbind".
640 .TS
641 lb2 lb2 lb2 lb2 lb1
642 lb | l l l l l.
643 make-shared make-slave make-priv make-unbind
644 _
645 shared shared slave/priv [1] priv unbind
646 slave slave+shared slave [2] priv unbind
647 slave+shared slave+shared slave priv unbind
648 private shared priv [2] priv unbind
649 unbindable shared unbind [2] priv unbind
650 .TE
651 .sp 1
652 Note the following details to the table:
653 .IP [1] 4
654 If a shared mount is the only mount in its peer group,
655 making it a slave automatically makes it private.
656 .IP [2]
657 Slaving a nonshared mount has no effect on the mount.
658 .\"
659 .SS Bind (MS_BIND) semantics
660 Suppose that the following command is performed:
661 .PP
662 .in +4n
663 .EX
664 mount \-\-bind A/a B/b
665 .EE
666 .in
667 .PP
668 Here,
669 .I A
670 is the source mount,
671 .I B
672 is the destination mount,
673 .I a
674 is a subdirectory path under the mount point
675 .IR A ,
676 and
677 .I b
678 is a subdirectory path under the mount point
679 .IR B .
680 The propagation type of the resulting mount,
681 .IR B/b ,
682 depends on the propagation types of the mounts
683 .IR A
684 and
685 .IR B ,
686 and is summarized in the following table.
687 .PP
688 .TS
689 lb2 lb1 lb2 lb2 lb2 lb0
690 lb2 lb1 lb2 lb2 lb2 lb0
691 lb lb | l l l l l.
692 source(A)
693 shared private slave unbind
694 _
695 dest(B) shared shared shared slave+shared invalid
696 nonshared shared private slave invalid
697 .TE
698 .sp 1
699 Note that a recursive bind of a subtree follows the same semantics
700 as for a bind operation on each mount in the subtree.
701 (Unbindable mounts are automatically pruned at the target mount point.)
702 .PP
703 For further details, see
704 .I Documentation/filesystems/sharedsubtree.txt
705 in the kernel source tree.
706 .\"
707 .SS Move (MS_MOVE) semantics
708 Suppose that the following command is performed:
709 .PP
710 .in +4n
711 .EX
712 mount \-\-move A B/b
713 .EE
714 .in
715 .PP
716 Here,
717 .I A
718 is the source mount,
719 .I B
720 is the destination mount, and
721 .I b
722 is a subdirectory path under the mount point
723 .IR B .
724 The propagation type of the resulting mount,
725 .IR B/b ,
726 depends on the propagation types of the mounts
727 .IR A
728 and
729 .IR B ,
730 and is summarized in the following table.
731 .PP
732 .TS
733 lb2 lb1 lb2 lb2 lb2 lb0
734 lb2 lb1 lb2 lb2 lb2 lb0
735 lb lb | l l l l l.
736 source(A)
737 shared private slave unbind
738 _
739 dest(B) shared shared shared slave+shared invalid
740 nonshared shared private slave unbindable
741 .TE
742 .sp 1
743 Note: moving a mount that resides under a shared mount is invalid.
744 .PP
745 For further details, see
746 .I Documentation/filesystems/sharedsubtree.txt
747 in the kernel source tree.
748 .\"
749 .SS Mount semantics
750 Suppose that we use the following command to create a mount:
751 .PP
752 .in +4n
753 .EX
754 mount device B/b
755 .EE
756 .in
757 .PP
758 Here,
759 .I B
760 is the destination mount, and
761 .I b
762 is a subdirectory path under the mount point
763 .IR B .
764 The propagation type of the resulting mount,
765 .IR B/b ,
766 follows the same rules as for a bind mount,
767 where the propagation type of the source mount
768 is considered always to be private.
769 .\"
770 .SS Unmount semantics
771 Suppose that we use the following command to tear down a mount:
772 .PP
773 .in +4n
774 .EX
775 unmount A
776 .EE
777 .in
778 .PP
779 Here,
780 .I A
781 is a mount on
782 .IR B/b ,
783 where
784 .I B
785 is the parent mount and
786 .I b
787 is a subdirectory path under the mount point
788 .IR B .
789 If
790 .B B
791 is shared, then all most-recently-mounted mounts at
792 .I b
793 on mounts that receive propagation from mount
794 .I B
795 and do not have submounts under them are unmounted.
796 .\"
797 .SS The /proc/[pid]/mountinfo "propagate_from" tag
798 The
799 .I propagate_from:X
800 tag is shown in the optional fields of a
801 .IR /proc/[pid]/mountinfo
802 record in cases where a process can't see a slave's immediate master
803 (i.e., the pathname of the master is not reachable from
804 the filesystem root directory)
805 and so cannot determine the
806 chain of propagation between the mounts it can see.
807 .PP
808 In the following example, we first create a two-link master-slave chain
809 between the mounts
810 .IR /mnt ,
811 .IR /tmp/etc ,
812 and
813 .IR /mnt/tmp/etc .
814 Then the
815 .BR chroot (1)
816 command is used to make the
817 .IR /tmp/etc
818 mount point unreachable from the root directory,
819 creating a situation where the master of
820 .IR /mnt/tmp/etc
821 is not reachable from the (new) root directory of the process.
822 .PP
823 First, we bind mount the root directory onto
824 .IR /mnt
825 and then bind mount
826 .IR /proc
827 at
828 .IR /mnt/proc
829 so that after the later
830 .BR chroot (1)
831 the
832 .BR proc (5)
833 filesystem remains visible at the correct location
834 in the chroot-ed environment.
835 .PP
836 .in +4n
837 .EX
838 # \fBmkdir \-p /mnt/proc\fP
839 # \fBmount \-\-bind / /mnt\fP
840 # \fBmount \-\-bind /proc /mnt/proc\fP
841 .EE
842 .in
843 .PP
844 Next, we ensure that the
845 .IR /mnt
846 mount is a shared mount in a new peer group (with no peers):
847 .PP
848 .in +4n
849 .EX
850 # \fBmount \-\-make\-private /mnt\fP # Isolate from any previous peer group
851 # \fBmount \-\-make\-shared /mnt\fP
852 # \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
853 239 61 8:2 / /mnt ... shared:102
854 248 239 0:4 / /mnt/proc ... shared:5
855 .EE
856 .in
857 .PP
858 Next, we bind mount
859 .IR /mnt/etc
860 onto
861 .IR /tmp/etc :
862 .PP
863 .in +4n
864 .EX
865 # \fBmkdir \-p /tmp/etc\fP
866 # \fBmount \-\-bind /mnt/etc /tmp/etc\fP
867 # \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP
868 239 61 8:2 / /mnt ... shared:102
869 248 239 0:4 / /mnt/proc ... shared:5
870 267 40 8:2 /etc /tmp/etc ... shared:102
871 .EE
872 .in
873 .PP
874 Initially, these two mounts are in the same peer group,
875 but we then make the
876 .IR /tmp/etc
877 a slave of
878 .IR /mnt/etc ,
879 and then make
880 .IR /tmp/etc
881 shared as well,
882 so that it can propagate events to the next slave in the chain:
883 .PP
884 .in +4n
885 .EX
886 # \fBmount \-\-make\-slave /tmp/etc\fP
887 # \fBmount \-\-make\-shared /tmp/etc\fP
888 # \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP
889 239 61 8:2 / /mnt ... shared:102
890 248 239 0:4 / /mnt/proc ... shared:5
891 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
892 .EE
893 .in
894 .PP
895 Then we bind mount
896 .IR /tmp/etc
897 onto
898 .IR /mnt/tmp/etc .
899 Again, the two mounts are initially in the same peer group,
900 but we then make
901 .IR /mnt/tmp/etc
902 a slave of
903 .IR /tmp/etc :
904 .PP
905 .in +4n
906 .EX
907 # \fBmkdir \-p /mnt/tmp/etc\fP
908 # \fBmount \-\-bind /tmp/etc /mnt/tmp/etc\fP
909 # \fBmount \-\-make\-slave /mnt/tmp/etc\fP
910 # \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP
911 239 61 8:2 / /mnt ... shared:102
912 248 239 0:4 / /mnt/proc ... shared:5
913 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
914 273 239 8:2 /etc /mnt/tmp/etc ... master:105
915 .EE
916 .in
917 .PP
918 From the above, we see that
919 .IR /mnt
920 is the master of the slave
921 .IR /tmp/etc ,
922 which in turn is the master of the slave
923 .IR /mnt/tmp/etc .
924 .PP
925 We then
926 .BR chroot (1)
927 to the
928 .IR /mnt
929 directory, which renders the mount with ID 267 unreachable
930 from the (new) root directory:
931 .PP
932 .in +4n
933 .EX
934 # \fBchroot /mnt\fP
935 .EE
936 .in
937 .PP
938 When we examine the state of the mounts inside the chroot-ed environment,
939 we see the following:
940 .PP
941 .in +4n
942 .EX
943 # \fBcat /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
944 239 61 8:2 / / ... shared:102
945 248 239 0:4 / /proc ... shared:5
946 273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102
947 .EE
948 .in
949 .PP
950 Above, we see that the mount with ID 273
951 is a slave whose master is the peer group 105.
952 The mount point for that master is unreachable, and so a
953 .IR propagate_from
954 tag is displayed, indicating that the closest dominant peer group
955 (i.e., the nearest reachable mount in the slave chain)
956 is the peer group with the ID 102 (corresponding to the
957 .IR /mnt
958 mount point before the
959 .BR chroot (1)
960 was performed.
961 .\"
962 .SH VERSIONS
963 Mount namespaces first appeared in Linux 2.4.19.
964 .SH CONFORMING TO
965 Namespaces are a Linux-specific feature.
966 .\"
967 .SH NOTES
968 The propagation type assigned to a new mount depends
969 on the propagation type of the parent mount.
970 If the mount has a parent (i.e., it is a non-root mount
971 point) and the propagation type of the parent is
972 .BR MS_SHARED ,
973 then the propagation type of the new mount is also
974 .BR MS_SHARED .
975 Otherwise, the propagation type of the new mount is
976 .BR MS_PRIVATE .
977 .PP
978 Notwithstanding the fact that the default propagation type
979 for new mount is in many cases
980 .BR MS_PRIVATE ,
981 .BR MS_SHARED
982 is typically more useful.
983 For this reason,
984 .BR systemd (1)
985 automatically remounts all mounts as
986 .BR MS_SHARED
987 on system startup.
988 Thus, on most modern systems, the default propagation type is in practice
989 .BR MS_SHARED .
990 .PP
991 Since, when one uses
992 .BR unshare (1)
993 to create a mount namespace,
994 the goal is commonly to provide full isolation of the mounts
995 in the new namespace,
996 .BR unshare (1)
997 (since
998 .IR util\-linux
999 version 2.27) in turn reverses the step performed by
1000 .BR systemd (1),
1001 by making all mounts private in the new namespace.
1002 That is,
1003 .BR unshare (1)
1004 performs the equivalent of the following in the new mount namespace:
1005 .PP
1006 .in +4n
1007 .EX
1008 mount \-\-make\-rprivate /
1009 .EE
1010 .in
1011 .PP
1012 To prevent this, one can use the
1013 .IR "\-\-propagation\ unchanged"
1014 option to
1015 .BR unshare (1).
1016 .PP
1017 An application that creates a new mount namespace directly using
1018 .BR clone (2)
1019 or
1020 .BR unshare (2)
1021 may desire to prevent propagation of mount events to other mount namespaces
1022 (as is done by
1023 .BR unshare (1)).
1024 This can be done by changing the propagation type of
1025 mounts in the new namespace to either
1026 .B MS_SLAVE
1027 or
1028 .BR MS_PRIVATE ,
1029 using a call such as the following:
1030 .PP
1031 .in +4n
1032 .EX
1033 mount(NULL, "/", MS_SLAVE | MS_REC, NULL);
1034 .EE
1035 .in
1036 .PP
1037 For a discussion of propagation types when moving mounts
1038 .RB ( MS_MOVE )
1039 and creating bind mounts
1040 .RB ( MS_BIND ),
1041 see
1042 .IR Documentation/filesystems/sharedsubtree.txt .
1043 .\"
1044 .\" ============================================================
1045 .\"
1046 .SS Restrictions on mount namespaces
1047 Note the following points with respect to mount namespaces:
1048 .IP [1] 4
1049 Each mount namespace has an owner user namespace.
1050 As explained above, when a new mount namespace is created,
1051 its mount list is initialized as a copy of the mount list
1052 of another mount namespace.
1053 If the new namespace and the namespace from which the mount list
1054 was copied are owned by different user namespaces,
1055 then the new mount namespace is considered
1056 .IR "less privileged" .
1057 .IP [2]
1058 When creating a less privileged mount namespace,
1059 shared mounts are reduced to slave mounts.
1060 This ensures that mappings performed in less
1061 privileged mount namespaces will not propagate to more privileged
1062 mount namespaces.
1063 .IP [3]
1064 Mounts that come as a single unit from a more privileged mount namespace are
1065 locked together and may not be separated in a less privileged mount
1066 namespace.
1067 (The
1068 .BR unshare (2)
1069 .B CLONE_NEWNS
1070 operation brings across all of the mounts from the original
1071 mount namespace as a single unit,
1072 and recursive mounts that propagate between
1073 mount namespaces propagate as a single unit.)
1074 .IP
1075 In this context, "may not be separated" means that the mounts
1076 are locked so that they may not be individually unmounted.
1077 Consider the following example:
1078 .IP
1079 .RS
1080 .in +4n
1081 .EX
1082 $ \fBsudo sh\fP
1083 # \fBmount \-\-bind /dev/null /etc/shadow\fP
1084 # \fBcat /etc/shadow\fP # Produces no output
1085 .EE
1086 .in
1087 .RE
1088 .IP
1089 The above steps, performed in a more privileged mount namespace,
1090 have created a bind mount that
1091 obscures the contents of the shadow password file,
1092 .IR /etc/shadow .
1093 For security reasons, it should not be possible to unmount
1094 that mount in a less privileged mount namespace,
1095 since that would reveal the contents of
1096 .IR /etc/shadow .
1097 .IP
1098 Suppose we now create a new mount namespace
1099 owned by a new user namespace.
1100 The new mount namespace will inherit copies of all of the mounts
1101 from the previous mount namespace.
1102 However, those mounts will be locked because the new mount namespace
1103 is less privileged.
1104 Consequently, an attempt to unmount the mount fails as show
1105 in the following step:
1106 .IP
1107 .RS
1108 .in +4n
1109 .EX
1110 # \fBunshare \-\-user \-\-map\-root\-user \-\-mount \e\fP
1111 \fBstrace \-o /tmp/log \e\fP
1112 \fBumount /mnt/dir\fP
1113 umount: /etc/shadow: not mounted.
1114 # \fBgrep \(aq^umount\(aq /tmp/log\fP
1115 umount2("/etc/shadow", 0) = \-1 EINVAL (Invalid argument)
1116 .EE
1117 .in
1118 .RE
1119 .IP
1120 The error message from
1121 .BR mount (8)
1122 is a little confusing, but the
1123 .BR strace (1)
1124 output reveals that the underlying
1125 .BR umount2 (2)
1126 system call failed with the error
1127 .BR EINVAL ,
1128 which is the error that the kernel returns to indicate that
1129 the mount is locked.
1130 .IP
1131 Note, however, that it is possible to stack (and unstack) a
1132 mount on top of one of the inherited locked mounts in a
1133 less privileged mount namespace:
1134 .IP
1135 .in +4n
1136 .EX
1137 # \fBecho \(aqaaaaa\(aq > /tmp/a\fP # File to mount onto /etc/shadow
1138 # \fBunshare \-\-user \-\-map\-root\-user \-\-mount \e\fP
1139 \fBsh \-c \(aqmount \-\-bind /tmp/a /etc/shadow; cat /etc/shadow\(aq\fP
1140 aaaaa
1141 # \fBumount /etc/shadow\fP
1142 .EE
1143 .in
1144 .IP
1145 The final
1146 .BR umount (8)
1147 command above, which is performed in the initial mount namespace,
1148 makes the original
1149 .I /etc/shadow
1150 file once more visible in that namespace.
1151 .IP [4]
1152 Following on from point [3],
1153 note that it is possible to unmount an entire subtree of mounts that
1154 propagated as a unit into a less privileged mount namespace,
1155 as illustrated in the following example.
1156 .IP
1157 First, we create new user and mount namespaces using
1158 .BR unshare (1).
1159 In the new mount namespace,
1160 the propagation type of all mounts is set to private.
1161 We then create a shared bind mount at
1162 .IR /mnt ,
1163 and a small hierarchy of mounts underneath that mount.
1164 .IP
1165 .in +4n
1166 .EX
1167 $ \fBPS1=\(aqns1# \(aq sudo unshare \-\-user \-\-map\-root\-user \e\fP
1168 \fB\-\-mount \-\-propagation private bash\fP
1169 ns1# \fBecho $$\fP # We need the PID of this shell later
1170 778501
1171 ns1# \fBmount \-\-make\-shared \-\-bind /mnt /mnt\fP
1172 ns1# \fBmkdir /mnt/x\fP
1173 ns1# \fBmount \-\-make\-private \-t tmpfs none /mnt/x\fP
1174 ns1# \fBmkdir /mnt/x/y\fP
1175 ns1# \fBmount \-\-make\-private \-t tmpfs none /mnt/x/y\fP
1176 ns1# \fBgrep /mnt /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
1177 986 83 8:5 /mnt /mnt rw,relatime shared:344
1178 989 986 0:56 / /mnt/x rw,relatime
1179 990 989 0:57 / /mnt/x/y rw,relatime
1180 .EE
1181 .in
1182 .IP
1183 Continuing in the same shell session,
1184 we then create a second shell in a new user namespace and a new
1185 (less privileged) mount namespace and
1186 check the state of the propagated mounts rooted at
1187 .IR /mnt .
1188 .IP
1189 .in +4n
1190 .EX
1191 ns1# \fBPS1=\(aqns2# \(aq unshare \-\-user \-\-map\-root\-user \e\fP
1192 \fB\-\-mount \-\-propagation unchanged bash\fP
1193 ns2# \fBgrep /mnt /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
1194 1239 1204 8:5 /mnt /mnt rw,relatime master:344
1195 1240 1239 0:56 / /mnt/x rw,relatime
1196 1241 1240 0:57 / /mnt/x/y rw,relatime
1197 .EE
1198 .in
1199 .IP
1200 Of note in the above output is that the propagation type of the mount
1201 .I /mnt
1202 has been reduced to slave, as explained in point [2].
1203 This means that submount events will propagate from the master
1204 .I /mnt
1205 in "ns1", but propagation will not occur in the opposite direction.
1206 .IP
1207 From a separate terminal window, we then use
1208 .BR nsenter (1)
1209 to enter the mount and user namespaces corresponding to "ns1".
1210 In that terminal window, we then recursively bind mount
1211 .IR /mnt/x
1212 at the location
1213 .IR /mnt/ppp .
1214 .IP
1215 .in +4n
1216 .EX
1217 $ \fBPS1=\(aqns3# \(aq sudo nsenter \-t 778501 \-\-user \-\-mount\fP
1218 ns3# \fBmount \-\-rbind \-\-make\-private /mnt/x /mnt/ppp\fP
1219 ns3# \fBgrep /mnt /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
1220 986 83 8:5 /mnt /mnt rw,relatime shared:344
1221 989 986 0:56 / /mnt/x rw,relatime
1222 990 989 0:57 / /mnt/x/y rw,relatime
1223 1242 986 0:56 / /mnt/ppp rw,relatime
1224 1243 1242 0:57 / /mnt/ppp/y rw,relatime shared:518
1225 .EE
1226 .in
1227 .IP
1228 Because the propagation type of the parent mount,
1229 .IR /mnt ,
1230 was shared, the recursive bind mount propagated a small subtree of
1231 mounts under the slave mount
1232 .I /mnt
1233 into "ns2",
1234 as can be verified by executing the following command in that shell session:
1235 .IP
1236 .in +4n
1237 .EX
1238 ns2# \fBgrep /mnt /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
1239 1239 1204 8:5 /mnt /mnt rw,relatime master:344
1240 1240 1239 0:56 / /mnt/x rw,relatime
1241 1241 1240 0:57 / /mnt/x/y rw,relatime
1242 1244 1239 0:56 / /mnt/ppp rw,relatime
1243 1245 1244 0:57 / /mnt/ppp/y rw,relatime master:518
1244 .EE
1245 .in
1246 .IP
1247 While it is not possible to unmount a part of the propagated subtree
1248 .RI ( /mnt/ppp/y )
1249 in "ns2",
1250 it is possible to unmount the entire subtree,
1251 as shown by the following commands:
1252 .IP
1253 .in +4n
1254 .EX
1255 ns2# \fBumount /mnt/ppp/y\fP
1256 umount: /mnt/ppp/y: not mounted.
1257 ns2# \fBumount \-l /mnt/ppp | sed \(aqs/ \- .*//\(aq\fP # Succeeds...
1258 ns2# \fBgrep /mnt /proc/self/mountinfo\fP
1259 1239 1204 8:5 /mnt /mnt rw,relatime master:344
1260 1240 1239 0:56 / /mnt/x rw,relatime
1261 1241 1240 0:57 / /mnt/x/y rw,relatime
1262 .EE
1263 .in
1264 .IP [5]
1265 The
1266 .BR mount (2)
1267 flags
1268 .BR MS_RDONLY ,
1269 .BR MS_NOSUID ,
1270 .BR MS_NOEXEC ,
1271 and the "atime" flags
1272 .RB ( MS_NOATIME ,
1273 .BR MS_NODIRATIME ,
1274 .BR MS_RELATIME )
1275 settings become locked
1276 .\" commit 9566d6742852c527bf5af38af5cbb878dad75705
1277 .\" Author: Eric W. Biederman <ebiederm@xmission.com>
1278 .\" Date: Mon Jul 28 17:26:07 2014 -0700
1279 .\"
1280 .\" mnt: Correct permission checks in do_remount
1281 .\"
1282 when propagated from a more privileged to
1283 a less privileged mount namespace,
1284 and may not be changed in the less privileged mount namespace.
1285 .IP
1286 This point is illustrated in the following example where,
1287 in a more privileged mount namespace,
1288 we create a bind mount that is marked as read-only.
1289 For security reasons,
1290 it should not be possible to make the mount writable in
1291 a less privileged mount namespace, and indeed the kernel prevents this:
1292 .IP
1293 .RS
1294 .in +4n
1295 .EX
1296 $ \fBsudo mkdir /mnt/dir\fP
1297 $ \fBsudo mount \-\-bind \-o ro /some/path /mnt/dir\fP
1298 $ \fBsudo unshare \-\-user \-\-map\-root\-user \-\-mount \e\fP
1299 \fBmount \-o remount,rw /mnt/dir\fP
1300 mount: /mnt/dir: permission denied.
1301 .EE
1302 .in
1303 .RE
1304 .IP [6]
1305 .\" (As of 3.18-rc1 (in Al Viro's 2014-08-30 vfs.git#for-next tree))
1306 A file or directory that is a mount point in one namespace that is not
1307 a mount point in another namespace, may be renamed, unlinked, or removed
1308 .RB ( rmdir (2))
1309 in the mount namespace in which it is not a mount point
1310 (subject to the usual permission checks).
1311 Consequently, the mount point is removed in the mount namespace
1312 where it was a mount point.
1313 .IP
1314 Previously (before Linux 3.18),
1315 .\" mtk: The change was in Linux 3.18, I think, with this commit:
1316 .\" commit 8ed936b5671bfb33d89bc60bdcc7cf0470ba52fe
1317 .\" Author: Eric W. Biederman <ebiederman@twitter.com>
1318 .\" Date: Tue Oct 1 18:33:48 2013 -0700
1319 .\"
1320 .\" vfs: Lazily remove mounts on unlinked files and directories.
1321 attempting to unlink, rename, or remove a file or directory
1322 that was a mount point in another mount namespace would result in the error
1323 .BR EBUSY .
1324 That behavior had technical problems of enforcement (e.g., for NFS)
1325 and permitted denial-of-service attacks against more privileged users
1326 (i.e., preventing individual files from being updated
1327 by bind mounting on top of them).
1328 .SH EXAMPLES
1329 See
1330 .BR pivot_root (2).
1331 .SH SEE ALSO
1332 .BR unshare (1),
1333 .BR clone (2),
1334 .BR mount (2),
1335 .BR mount_setattr (2),
1336 .BR pivot_root (2),
1337 .BR setns (2),
1338 .BR umount (2),
1339 .BR unshare (2),
1340 .BR proc (5),
1341 .BR namespaces (7),
1342 .BR user_namespaces (7),
1343 .BR findmnt (8),
1344 .BR mount (8),
1345 .BR pam_namespace (8),
1346 .BR pivot_root (8),
1347 .BR umount (8)
1348 .PP
1349 .IR Documentation/filesystems/sharedsubtree.txt
1350 in the kernel source tree.