Re: [RCF] [PATCH] unprivileged mount/umount

[Ram <linuxram@us.ibm.com>]

On Wed, 2005-05-11 at 14:28, Jamie Lokier wrote:
> Ram wrote:
> > What if proc filesystem is removed from the kernel?
> > 
> > Ability to access some other namespace through the proc filesystem does
> > not look clean. I think it should be cleanly supported through VFS.
> 
> You don't have to use /proc/NNN/root - that's just one convenient way
> to do it.
> 
> Other ways are
> 
>     run_in_namespace mount -t bind / /var/namespaces/$NAME
> 
> and
> 
>     clone + open("/") + pass to parent using unix socket
> 
> which I think both work already.
> 
> > Also cd'ing into a new namespace just allows you to browse through
> > the other namespace. But it does not effectively change the process's
> > namespace.  Things like mount in the other namespace will be failed
> > by check_mount() anyway.
> 
> That's correct.
> 
> > I think, we need sys calls like sys_cdnamespace() which switches to a
> > new namespace.
> 
> Can you give a reason why sys_chdir() shouldn't have that behaviour?

Do you mean to say you want to change the namespace when a process
changes to a directory which belongs to that namespace?

Well it makes it totally confusing. A user would start seeing different
set of mounts suddenly as he changes directories beloning to different
namespaces. I am not sure, if changing namespace implicitly is a good
idea. Not saying its a bad idea, but seems to change my notion of
namespaces completely. 

I think a process should have access to one
namespace at any given point in time, and should have the ability
to explicitly switch to a different namespace of its choice, provided
it has enough access permission to that namespace.

having the ability to access two namespaces simultaneously can allow
cross contamination. Which essentially makes namespaces as a concept
irrelevent.

RP

> 
> > Effectively the process's current->namespace has to be modified,
> > for the process to be effectively work in the new namespace.
> 
> Or just remove current->namespace.  It's entire purpose seems to be to
> prevent namespaces from being first class objects.  The idea of
> "current namespace" is adequately represented by
> current->fs->mnt_root->mnt_namespace IMHO.
> 
> -- Jamie