On Wed, Apr 20, 2005 at 18:09:21 +0100, Al Viro wrote: > On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote: > > Reading through the thread I assume the requirement is: > > > > 1) A User being able to create his own VFS-mount environment > > 2) being able to use the same VFS-mount environment from > > multiple login sessions. > > 3) Being able to switch some processes to some other > > VFS-mount environment. > > Excuse me, but could somebody give coherent rationale for such requirements? > _Especially_ for joining existing group by completely unrelated process - > something we don't do for any other component of process.
I think I can. And I think I can modify the proposal to something a bit
more sane.
The problem is: The mount should be accessible only by processes started
by the authorized user, but not by other user, including root, who is
capable of changing their uid to the authorized user's id.
The solution can be: The mount is only accessible to the process group
of that user's session. That's easy -- the login process is created
with new namespace.
Now how to allow the user to have that mountpoint accessible from all
sessions? Well, we can already pass open file descriptor to files
inside that mount to unrelated processes along unix domain sockets. So
what is left is being able to mount --bind a directory by it's
filehandle (since it does not have a path in our namespace).
This allows creating a "mount-agent", that would work similar to
ssh-agnet or gpg-agent, but instead of passing secret keys, it would
pass descriptors to that user's mount roots and it's client would bind
them. This agent can do whatever authentication is deemed appropriate
for that mountpoint.
Note however, that it's really hard to protect something against root,
because root can ptrace any process.
Well, being able to mount bind file descriptor might be useful for other
purposes as well and should not be hard to do. Unless you or somebody
finds a security problem with it, but I don't see any. Process having
a directory handle can chdir there anyway, so this does not add it extra
access.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[EMAIL
PROTECTED]>
signature.asc
Description: Digital signature
