Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Eric Van Hensbergen <ericvh@gmail.com>]

On 4/20/05, Al Viro <viro@parcelfarce.linux.theplanet.co.uk> wrote:
> 
> 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.
> 
> 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
> >

I think this enables a more secure environment for users when they
mount/bind their own file systems (be it network or synthetic).   It
helps prevent them from "spoofing" files and/or resources for users
other than themselves.  Security exposure for "system" files can be
limited by preventing users from mounting/binding over secure
locations and by enforcing nosuid/nosgid on user mounted file systems.
 Since there is no way to get at the "private" namespace, its contents
are "safe" from otherwise privileged users of the system (I'm not sure
if I agree with this, but I think that is part of what sent us down
this thread in the first place).

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

These requirements are less clear to me - although it might be useful
to structure things in such a way that it is easy to recreate a
VFS-mount environment.  To a certain extent the information in
/proc/x/mounts gives this information, but I'm unclear on how this
might impact synthetic file systems.

Another alternative is to allow easy re-export of a constructed
VFS-mount environment so that it could be mounted/bound into other
environments.  The Plan 9 /srv (3) device kind of works this way.  I
assume that is some of the intent under the shared subtree stuff as
well.

Of course that doesn't answer the question of why you need to do these
things in the first place.  One case is when you've opened up a remote
file system in one window under a private namespace and realize you
need access to those files in another window -- opening up a new
connection to the server from the other window seems somewhat heavy
weight -- I imagine the same thing would be the case in a synthetic
file system case (like a user-space encrypted file system).

In Plan 9, the connection to the server (whether remote or local
synthetic) would be represented by a handle in the /srv device.  This
single instance can then be mounted onto a particular process'
namespace, and all that is required to share the instance is the /srv
handle.  The /srv handles can be per-user or just protected with
normal file system permissions (I guess this is sorta similar to Ram's
device suggestion).

All in all, I think these last two requirements represent a much
tougher problem and there very well may be a better solution to what
they are trying to do.  Its also worth noting (as I think someone did)
that this invalidates private namespace's prevention of unauthorized
"super-user" access to user files (which is somewhat bogus anyways).

      -eric