LWN: Comments on "Shared subtrees"

Shared subtrees

abartlet — 2006-01-04T04:23:41+00:00

Closer to home, this is also the behaviour of smbmount, when the helper binary (smbmnt) is setuid.

Shared subtrees

linuxram — 2005-12-01T11:34:41+00:00

shared subtrees allows you to create identical mount trees at different locations. It does more than that, but in general it makes sure that the
subtrees 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 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).

Shared subtrees

linuxram — 2005-12-01T11:21:26+00:00

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.

Otherwise I feel the article has clearly and concisely touched upon this rather complicated idea.

Shared subtrees

csamuel — 2005-11-26T06:14:47+00:00

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 subtrees

proski — 2005-11-15T02:06:22+00:00

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 subtrees

lacostej — 2005-11-12T09:59:47+00:00

How do shared trees and chroot relate?
Is it possible to implement some kind of chroot using this?

Shared subtrees

elanthis — 2005-11-12T00:06:43+00:00

If the rule is "any directory the user *owns*" then world-writable directories wouldn't be a big problem.

Shared subtrees

nix — 2005-11-11T11:05:24+00:00

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 subtrees

hazelsct — 2005-11-10T23:12:32+00:00

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 subtrees

iabervon — 2005-11-10T19:22:56+00:00

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 subtrees

pointwood — 2005-11-10T19:13:11+00:00

Yeah, I love the laughs I usually get while reading LWN :)

Shared subtrees

smoogen — 2005-11-10T17:37:19+00:00

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 subtrees

rfunk — 2005-11-10T17:25:18+00:00

mount --bind /subtree /subtree
mount --make-unbindable /subtree

Looks like a race-condition vulnerability to me.

Shared subtrees

jzbiciak — 2005-11-10T14:58:50+00:00

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 subtrees

petebull — 2005-11-10T12:17:50+00:00

I like the filename on the mounted cdrom :)

Good pun.

Shared subtrees

nix — 2005-11-10T11:34:14+00:00

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.)

Corrected

corbet — 2005-11-10T03:56:11+00:00

Yes, it should. Fixed now.

Shared subtrees

npj — 2005-11-10T03:52:37+00:00

Should this command example about 60% of the way through the article:
mount --bind /mnt /mnt
mount --make-shared /subtree

Read like this instead:
mount --bind /mnt /mnt
mount --make-shared /mnt