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

[Jamie Lokier <jamie@shareable.org>]

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

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

-- Jamie