Al Viro wrote:
> Most of the code is already there - do_fork() has to do such stuff anyway.
> So how about adding sys_unshare(flags) that would do that job? Flags would
> correspond to those of clone(2), except that all these guys would be
> "what do we unshare" instead of "what do we leave shared".
That would let a program split off into its own namespace, but that's
not really what's needed for FUSE.
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.
For example, as a non-root user I should be able to mount an "ftpfs"
or "sshfs" on /home/jamie/mnt/remote in one shell window, and be able
to cd inside that directory from a different shell window. But other
users, including root, should not be able to see the mounted content
of that directory. (The mounted fs is really just an interface to a
program owned by me - a program running ftp or ssh in this case).
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.
The shared subtree mechanism seems like it has the basic ideas for this.
> b) I _really_ don't like the idea of messing with the parent. Make it
> a shell builtin if you want to affect shell behaviour; the same reason
> why cd is a builtin and not an external command.
I agree. That's just a poor hack to let a "usermount" program alter
the namespace of the shell it's called from. It won't work in general.
> c) I would be really, really careful with implications of "let user
> do whatever he wants" - that certainly should include bindings and
> that can create heaps of fun for suid stuff. More comments when
> I get around to digging through FUSE thread...
Probably the best thing to do for suid programs is this:
- Have a namespace per user. The user's namespace will be entered
by the "login" program somehow.
- 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.
- Mounts done by the user are private to the per-user namespace.
- Mounts done by the user are still restricted to directories writable
by the user, so he cannot modify /etc or /usr - your /etc/shadow
attack is not possible.
- suid programs run by the user inherit the same per-user namespace.
In other words, the per-user namespace is entered at login time
(by the login program doing a syscall), not when changing uid.
In this way, a user can pass a private pathname to an suid
program, and the suid program will be able to operate on that
file properly.
-- 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
