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

[Cedric Le Goater <clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>]

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

> 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 ?

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

C.