Al Viro wrote: > On Wed, Apr 20, 2005 at 10:45:58AM +0100, Jamie Lokier wrote: > > For FUSE, what's needed is that a user can mount something, and the > > mounted fs is visible only to that user, but it's visible to _all_ of > > the user's processes. > > So get that namespace as soon as you log in.
Yes. How? It is usual to log in on multiple terminals. You'd _usually_ want virtual filesystems mounted in one terminal to be visisble in others. Hmm. A fairly radical change to the login process would be able to do it: have login pass the terminal file descriptor to a per-user process which spawns user login shells from a common namespace. That would work with the current CLONE_NEWNS mechanism :) It's quite a radical change to the way logins are done, though. > > We think namespaces are a nice way to do that: making a user-owned > > filesystem only visible to a user. But the mechanism of CLONE_NEWNS > > does not work, because it presumes namespace divisions are only > > propagated over parent-child divisions, like environment variables. > > > What we really want is a mount point that propagates across all the > > processes owned by one user, but is not there for other users. > > This is almost certainly bogus. Same user can easily want several > different environments set on the same box. I agree, but didn't say that before as the explanation is complicated enough. It shouldn't be literally per-user - it should be possible for a user to have several environment _when_ they want that. chroot-jail style virtual server environments require that too. But that shouldn't be the only option - because it would be horrible to use. If I login on multiple terminals, I normally want to mount filesystems in /home/jamie/mnt on one terminal, and use them on another. > > - Have a namespace per user. The user's namespace will be entered > > by the "login" program somehow. > > Trivial right now - just have libpam do that. How can libpam join the user's existing namespace? Having a separate usermount-namespace for each login of the same user would not be nice to use. > > - All logins to the same user acquire the same per-user namespace. > > This isn't possible at the moment; it would be a kernel extension > > + administrative change to login. > > No. Identical setup at login time - sure. Enforced _single_ namespace > is just plain wrong. Moreover, "all user's processes" is the wrong answer > to practically any question (well, aside of "what processes do you kill > when you get rid of luser's account"). I agree. Certainly the kernel should not be looking at uid for this. The actual determination of which processes share mounts should be determined entirely by userspace. But right now, the kernel doesn't provide a mechanism (that I know of) whereby a new login shell can use the namespace of an existing process - something that would be desirable if it were possible. The idea I gave at the start of this mail - a daemon per user spawning login shells using a shared namespace - would work using the available CLONE_NEWNS mechanism. But it doesn't fit very well with libpam, nor with the usual tree relationship of parent-child processes when using "su" and such. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
