[RFC][PATCH 0/8][v2]: Enable multiple mounts of devpts

[Serge E. Hallyn]

Quoting Cedric Le Goater (clg at fr.ibm.com):
> >>
> >> (3) move mq_ns out of nsproxy.  where shall I put it then ? 
> >>
> >>     (3.1) task_struct ? 
> >>     (3.2) mnt namespace maybe ?
> > 
> > I think the last one is the way to go.
> > 
> > mnt_namespace points to mq_ns.
> > 
> > At clone(CLONE_NEWMNT), the new mnt namespace receives a copy of the
> > parent's mq_ns.
> 
> hmm, hmm, hmm, I still thinking about this.
> 
> > If a task does
> > 	mount -o newinstance -t mqueue none /dev/mqueue
> > then its current->nsproxy->mnt_namespace->mqns is switched
> > to point to a new instance of the mq_ns.
> > 
> > mnt_ns->mq_ns has pointers to the sb (and hence root dentry) of the
> > devpts fs.
> 
> [trying to understand what you have in mind ]
> 
> why not keep the 'struct vfsmount' in the mq_ns, as the code is doing 
> today ? the vfsmount holds both the root dentry and the superblock.

Yeah that's fine  :)

> > When a task does mq_open(name, flag), then name is in the mqueuefs
> > found in current->nsproxy->mnt_namespace->mqns.
> > 
> > But if a task does
> > 
> > 	clone(CLONE_NEWMNT);
> > 	mount --move /dev/mqueue /oldmqueue
> > 	mount -o newinstance -t mqueue none /dev/mqueue
> > 
> > then that task can find files for the old mqueuefs under
> > /oldmqueue, while mq_open() uses /dev/mqueue since that's
> > what it finds through its mnt_namespace.
> 
> That I don't like. 
> 
> Even though posix mqueue objects can outlive a process, I don't think 
> a process should be able to peek and poke in a message queue namespace 
> other than his. this is the basic principle of the namespaces : 
> isolation. Am I wrong ?

Yes you are wrong in this case.  In particular consider mounts
propagation, which allows you to to examine both a child namespace's
mounts namespace, and, through the child's /sys (presumably
mounted under /vs1/sys), his network namespace and eventually
device namespace.

> couldn't we just return EACCES ? (not posix) 

We could.  And if we think there is really no value in viewing
a child namespace's mqueuefs then we may as well.  I just want
to make it clear that the proposed semantics support it as an
option.

-serge