text: Not logged in
  Log in now
  Weekly Edition
  Recent Features
  LWN.net Weekly Edition for May 24, 2012
  A uTouch architecture introduction
  LWN.net Weekly Edition for May 17, 2012
  Tasting the Ice Cream Sandwich
  Highlights from the PostgreSQL 9.2 beta
  It should be noted that the patches merged into the mainline are not a
  complete solution for either of the above problems, but they are a step in
  that direction. The per-user namespaces example will be used in what
  follows to illustrate how the various subtree options work.
  Every filesystem in Linux is mounted within a specific namespace. The
  kernel has long supported the creation of multiple namespaces, but, in most
  situations, that feature is not used. So the typical Linux system has a
  single namespace which is shared between all processes on the system.
  When separate namespaces are used, they are usually in the context of
  sandboxing and isolation. There would be advantages, however, to making
  more extensive use of namespaces.
  Imagine, for starters, a simple filesystem hierarchy which looks something
  like the diagram at the right. Clearly, a few directories have been left
  out for simplicity. The only unusual thing is that a couple of directories
  have been created under /subtree for users "alice" and "bob". We
  would like to use those directories as the root for each user's own private
  view of the filesystem.
  The first step is to create a copy of the root filesystem under each user's
  subtree directory using bind mounts. The result of such an operation will
  look like the diagram below.
  This loss of isolation and explosion of mount points can be avoided through
  the use of "unbindable" mounts, a new feature added by the sharable
  subtrees patch. Said mounts cannot be
  bound into other places, and will not be propagated into new subtrees. So
  the administrator could execute a series of commands like:
  mount --bind /subtree /subtree
  mount --make-unbindable /subtree
  This incantation turns /subtree into a magic point which cannot be
  rebound. If, after this has been done, the administrator makes the
  per-user bind mounts of the root filesystem, the portion under
  /subtree will be pruned, with a result which looks like this:
  Now imagine that the system administrator mounts a CDROM under
  /mnt. The result will look like:
  Note that the CDROM mount is not visible in the per-user namespaces, so bob
  and alice will be unable to look at the contents of the CD. That might be the
  intended result, but imagine it's not, that the administrator wants all
  users to be able to see things mounted on /mnt. The answer is a
  "sharable" mount, one which is automatically propagated into every place
  where the original mount appears. So, the administrator need only perform
  another new incantation:
  mount --bind /mnt /mnt
  mount --make-shared /mnt
  Many administrators might rather just make the entire filesystem tree
  sharable, rather than try to anticipate where changes could be made. If
  the root is made sharable in this way, any new filesystems which are
  mounted will propagate throughout the tree. This propagation works all
  ways; if alice mounts the CD within her subtree, it will still appear in
  all of the subtrees.
  Of course, this behavior might not always be desirable. If, for example, bob is
  using FUSE to mount an "ssh filesystem" from a remote host, he would prefer
  that this filesystem not be visible to other users at all. But bob would
  still like to see filesystems mounted elsewhere, and does not want to give
  up the advantages of a shared subtree. The answer is yet another type of
  mount, called a "slave" mount. Slave mounts are selfish: they remain tied
  to their parent mount, and receive new mounts from there. Anything mounted
  underneath the slave mount, however, will not be propagated elsewhere. So
  each user can have his or her own filesystems which are not part of the
  global hierarchy:
  The shared subtrees patch also adds a "private" mount type, which is
  essentially how mounts in 2.6.14 and prior kernels work. A private mount
  will not be propagated to any other mounts, but it can (unlike an
  unbindable mount) be explicitly propagated via a bind operation.
  Internally, the patches create the concept of a "peer group," among which
  mount events are propagated. A new mnt_share field (a list of
  peers) has been added to the vfsmount structure for this purpose.
  A couple of other lists (mnt_slave_list and mnt_slave)
  have been added for keeping track of slave mount relationships. A new
  MNT_UNBINDABLE flag marks unbindable mounts. And, of course, a
  great deal of locking work has been done to make all of this work in a safe
  manner. Al Viro has worked with a few iterations of the shared subtrees
  patch, with the result that it is now considered to be ready for the
  mainline.
  The shared subtrees patch is a big step forward: it is a fundamental change
  to the virtual filesystem layer which greatly increases the flexibility in
  how namespaces can be populated and presented to users. What remains, at
  this point, is some work on the namespace side of things. Namespaces are
  still unnamed objects which can only be inherited from a parent process;
  there is no easy way to create and attach to a per-user namespace.
  Finishing the job will take some work, but, chances are, the hardest part
  of the problem has been solved.
  For more information, see the extensive
  documentation file shipped with the patch.
  Shared subtrees
  Posted Nov 10, 2005 3:52 UTC (Thu) by npj (guest, #4267)
  [Link]
  Read like this instead:
  mount --bind /mnt /mnt
  mount --make-shared /mnt
  ?
  Corrected
  Posted Nov 10, 2005 3:56 UTC (Thu) by corbet (editor, #1)
  [Link]
  Posted Nov 10, 2005 11:34 UTC (Thu) by nix (subscriber, #2304)
  [Link]
  Posted Nov 10, 2005 14:58 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
  [Link]
  STICKY.
  Posted Nov 11, 2005 11:05 UTC (Fri) by nix (subscriber, #2304)
  [Link]
  (And for those of us giving each user their own /tmp, well, we can turn the sticky bit off and fix up the permissions so that only that user can write to it :) )
  Posted Nov 12, 2005 0:06 UTC (Sat) by elanthis (guest, #6227)
  [Link]
  Posted Nov 26, 2005 6:14 UTC (Sat) by csamuel (✭ supporter ✭, #2624)
  [Link]
  Posted Jan 4, 2006 4:23 UTC (Wed) by abartlet (subscriber, #3928)
  [Link]
  Posted Nov 10, 2005 12:17 UTC (Thu) by petebull (guest, #7857)
  [Link]
  Posted Nov 10, 2005 19:13 UTC (Thu) by pointwood (guest, #2814)
  [Link]
  Posted Nov 10, 2005 17:25 UTC (Thu) by rfunk (subscriber, #4054)
  [Link]
  Posted Nov 10, 2005 19:22 UTC (Thu) by iabervon (subscriber, #722)
  [Link]
  Posted Nov 10, 2005 17:37 UTC (Thu) by smoogen (subscriber, #97)
  [Link]
  Posted Nov 10, 2005 23:12 UTC (Thu) by hazelsct (guest, #3659)
  [Link]
  Posted Nov 12, 2005 9:59 UTC (Sat) by lacostej (subscriber, #2760)
  [Link]
  Posted Nov 15, 2005 2:06 UTC (Tue) by proski (subscriber, #104)
  [Link]
  Posted Dec 1, 2005 11:34 UTC (Thu) by linuxram (subscriber, #22157)
  [Link]
  Chroot is a entirely different thing. It helps set a process up in a jail
  Once in a jail the process wont be able to access anything outside the directory tree. Neither do any of its children.
  But the combination of shared subtree and chroot togather have lot of applications. One example is mentioned in the article, where we can have a identical subtree for each user(thanks to shared subtree semantics). And each user can get jailed in its corresponding subtree (thanks to chroot).
  Posted Dec 1, 2005 11:21 UTC (Thu) by linuxram (subscriber, #22157)
  [Link]
  The namespace terminology is used in this article to mean identical subtrees within a given namespace.
  Otherwise I feel the article has clearly and concisely touched upon this rather complicated idea.
  RP
  Linux is a registered trademark of Linus Torvalds