Re: [RFC] User CLONE_NEWNS permission and rlimits

[Ritesh Kumar <digitalove@gmail.com>]

I am new to the list so please bear with me :-)

I have also be thinking about filesystem namespaces which are
completely under the user's own control. I was also thinking of them
being inherited and changed along the process heirarchy. So a given
process is allowed to change its namespace any way it likes and map it
to its parent's namespace.
More importantly, I was thinking in terms of having this entire
capability in the userspace itself. Instead of giving all the details
right here... let me redirect you to the page where I have set up the
prototype. You should be able to download the sample code (very small)
and browse through it to get an idea of what I had in mind. I also
have an article which explains what I was thinking. In essense, I was
thinking of splitting up the conceps of 1) accessing the filesystem on
the HDD/device and 2) setting up a namespace for accessing the files
into two separate concepts and bringing up 2) completely in the
userspace.
What do you think? I would like to have feedback on the idea.

http://www.cs.unc.edu/~ritesh/projects/perprocessfs.html

Ritesh

On 4/19/05, Ram <linuxram@us.ibm.com> wrote:
> On Tue, 2005-04-19 at 18:24, Eric Van Hensbergen wrote:
> > This is again related to the FUSE permission thread, but a slightly
> > different idea and without a slimy hack patch.
> >
> > I really want to enable users to be able to create private namespaces,
> > but I want to try and avoid creating a venerability by allowing them
> > to abuse system resources.  It looks like this can be done by adding
> > RLIMIT_NEWNS as a per-user resource limit, and tracking the number of
> > private namespaces a user has in the user_struct.  Any time a user
> > creates a private namespace (either via clone with CLONE_NEWNS) or any
> > other method, this limit is checked and the per user count is
> > incremented (in copy_namespace).  When namespaces are cleaned up (in
> > __put_namespace), the per-user count is decremented.
> >
> > Is this sufficient to cover any exposure?  What's the correct solution
> > for the shared sub-trees RFC?  Should there be something similar for
> > user mounts/binds?
> 
> A new namespace in a shared subtree realm can create number-of-
> private-namespaces number of mounts or binds depending on the number of
> binds and mounts in the shared tree.
> 
> for example if  there were 10 shared vfsmounts in the original
> namespace, a new private namespace will duplicate 10 of these, and
> any mount or bind attempted in any of these vfsmounts will double the
> number of mounts and binds.
> 
> Hence probably you may want to keep a tab on the number mounts and
> binds a user does, instead of keeping a tab on the number of namespaces
> a user creates.
> 
> RP
> 
> >
> >          -eric
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Rationality is the fundamental limitation to all human thought.