Saturday, January 19, 2013

REDHAT SHARED SUBTREES


Weekly editionKernelSecurityDistributionsContact UsSearchArchivesCalendarSubscribeWrite for LWNLWN.net FAQSponsors

Shared subtrees

[Posted November 8, 2005 by corbet]The shared subtrees patch set, written primarily by Ram Pai, has been in circulation for some time, but without a whole lot of discussion. Those patches have now been merged into the pre-2.6.15 mainline, so the time has come for a closer look. In short, shared subtrees allow a system administrator to configure, in great detail, how various filesystem mounts should appear in the tree, how they relate to each other, and how they propagate between namespaces. There are two motivations for this work:The "files as directories" feature of the reiser4 filesystem allows a user to create, via hard links, a directory which appears in multiple places in the filesystem. That feature has long been disabled due to the deadlock issues which it raised. Shared subtrees are a step toward implementing "files as directories" in a safe manner.The merging of the filesystems in user space patch, and some of the permissions issuesassociated with it, has increased the desire to be able to run users in their own filesystem namespaces. Per-user namespaces are currently awkward at best; shared subtrees will help make them easier to manage.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.Note that the /subtree tree has been bound into each user's namespace as well. This propagation cuts down on the isolation between users, since they can see each others' subtrees. As the number of users grows, it also complicates the namespaces considerably, as each set of subtrees must be replicated over and over.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 After this, /mnt is a sharable mount. Any changes made there will appear in any namespace where /mnt appears. The resulting tree would look something like this: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.(Log in to post comments)Shared subtreesPosted Nov 10, 2005 3:52 UTC (Thu) by npj (guest, #4267) [Link]Should this command example about 60% of the way through the article:mount --bind /mnt /mntmount --make-shared /subtreeRead like this instead:mount --bind /mnt /mntmount --make-shared /mnt?CorrectedPosted Nov 10, 2005 3:56 UTC (Thu) by corbet (editor, #1) [Link]Yes, it should. Fixed now.Shared subtreesPosted Nov 10, 2005 11:34 UTC (Thu) by nix (subscriber, #2304) [Link]One thing that might be useful here is a modification to mount(1) that allows the mounting of filesystems of specific types (listed in /etc/user-mountable-filesystems?) by any user *on top of any directory that user has write access to*. (I'm slightly concerned about /tmp, but not very. /tmp should probably be remounted separately in each user's subtree in any case in a system making use of this patch.)Shared subtreesPosted Nov 10, 2005 14:58 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]How about "any directory the user owns, or has write access to but does not have the sticky bit set"? Quick refresher on the sticky bit from the chmod(1) manpage:STICKY DIRECTORIES When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by root or their owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable.Shared subtreesPosted Nov 11, 2005 11:05 UTC (Fri) by nix (subscriber, #2304) [Link]Yes; that would mean that only world-writable directories (which strike me as a really bad idea) would be `problematic'.(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 :) )Shared subtreesPosted Nov 12, 2005 0:06 UTC (Sat) by elanthis (guest, #6227) [Link]If the rule is "any directory the user *owns*" then world-writable directories wouldn't be a big problem.Shared subtreesPosted Nov 26, 2005 6:14 UTC (Sat) by csamuel (✭ supporter ✭, #2624) [Link]DEC Ultrix did allow users to do NFS mounts onto directories that they owned. Whether this is a bug or a feature is left as an exercise for the reader. Shared subtreesPosted Jan 4, 2006 4:23 UTC (Wed) by abartlet (✭ supporter ✭, #3928) [Link]Closer to home, this is also the behaviour of smbmount, when the helper binary (smbmnt) is setuid.Shared subtreesPosted Nov 10, 2005 12:17 UTC (Thu) by petebull (guest, #7857) [Link]I like the filename on the mounted cdrom :) Good pun. Shared subtreesPosted Nov 10, 2005 19:13 UTC (Thu) by pointwood (guest, #2814) [Link]Yeah, I love the laughs I usually get while reading LWN :)Shared subtreesPosted Nov 10, 2005 17:25 UTC (Thu) by rfunk (subscriber, #4054) [Link]mount --bind /subtree /subtree mount --make-unbindable /subtree Looks like a race-condition vulnerability to me. Shared subtreesPosted Nov 10, 2005 19:22 UTC (Thu) by iabervon (subscriber, #722) [Link]Well, that case should be safe, since it happens before any users could be on the system (since the root directory of their namespaces hasn't been mounted yet, aside from anything else). Other uses might not be so safe, though.Shared subtreesPosted Nov 10, 2005 17:37 UTC (Thu) by smoogen (subscriber, #97) [Link]I think this will help make diskless workstations also more maintainable. In this case you can have a master tree that you keep patched and then have your subtrees which are then exported to each workstation. You can patch the master and see the patches show up cleanly in the multiple workstations without having to patch each workstation. (Except for files in the workstation that are not shared :)).Shared subtreesPosted Nov 10, 2005 23:12 UTC (Thu) by hazelsct (guest, #3659) [Link]Well, yes and no. You still need some extra hacks to make package post-install scripts get everything right in all of the /etc sub-directories for example. But you're right, this could make the process somewhat easier.Shared subtreesPosted Nov 12, 2005 9:59 UTC (Sat) by lacostej (guest, #2760) [Link]How do shared trees and chroot relate?Is it possible to implement some kind of chroot using this?Shared subtreesPosted Nov 15, 2005 2:06 UTC (Tue) by proski (subscriber, #104) [Link]My understanding is that chroot creates a new namespace whereas the shared subtrees patch configures relationships between the namespaces. The answer to your second question is probably negative. It would be like implementing mkdir using chmod.Shared subtreesPosted Dec 1, 2005 11:34 UTC (Thu) by linuxram (subscriber, #22157) [Link]shared subtrees allows you to create identical mount trees at different locations. It does more than that, but in general it makes sure that thesubtrees remain identical even after a series of mount and unmounts, in any of the subtrees.Chroot is a entirely different thing. It helps set a process up in a jailOnce 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).Shared subtreesPosted Dec 1, 2005 11:21 UTC (Thu) by linuxram (subscriber, #22157) [Link]the namespace terminology used here is bit off. In Linux a namespace is the entire mount-tree. A namespace can be accessed only by the processes that created that namespace and all its children provided the child has not forked off its own namespace.The namespace terminology is used in this article to mean identical subtrees within a given namespace. Other



http://lwn.net/Articles/159077/



No comments:

Post a Comment