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

[Ram]

On Wed, 2005-05-11 at 17:59, Jamie Lokier wrote:
> Ram wrote:
> > > 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. 
> 
> That happens _already_.  I'm not suggesting it, it's been there in the
> kernel for ages.
> 
> Let me explain how namespaces _really_ work in Linux.
> 
> For path lookup, mounts are just mappings from (dentry,vfsmnt) to
> (dentry,vfsmnt).  There's a unique vfsmnt for each
> (filesystem,namespace) pair, by the way.
> 
> During path lookup, each path component moves from one (dentry,vfsmnt)
> pair to the next.  vfsmnt doesn't change from one dentry to the next
> while following a path component.  But then, if there's a mount whose
> key is the current (dentry,vfsmnt) pair, the current pair is replaced
> by the value of the mount.
> 
> Notice how namespaces aren't involved in path lookup at all.
> 
> That's nothing new: it's what Linux does already.
> 
> If that seems confusing, it's because _bind mounts_ are confusing.
> 
> Namespaces don't really exist.  When you create a new namespace with
> CLONE_NEWNS, all that really happens is a lot of bind mounts, to
> create a copy of the current directory tree, and then chrooting into
> that tree (in effect).
> 
> > having the ability to access two namespaces simultaneously can allow
> > cross contamination. Which essentially makes namespaces as a concept
> > irrelevent.
> 
> Cross contamination is already possible, using file descriptor passing
> or ptrace().

I am yet to convince myself that this is possible. Maybe possible and if
its possible we should close those holes.

> 
> Also, your suggested new syscall for accessing another namespace would
> have exactly the same effect, wouldn't it? :)

No it wont. a process can contaminate namespaces if the process has
access to both the namespace simultaneously.  With the proposed syscall,
the process would have access to one namespace at any given point in
time. There cannot be a instance where a process will have access
to vfsmounts belonging to two different namespaces. 

So I dont' think contamination is possible. By contamination I mean
'ability for a process to bind mount from one namespace to other'


RP



> 
> -- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/