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

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

Eric W. Biederman wrote:
> "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
> 
>>>     (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.
>>
>> 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.
>>
>> 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.
> 
> Serge if we can make the lookup a pure mount namespace operation
> i.e. a well known path.  Than I don't have any problems with it.
> Otherwise it looks like abuse of the mount namespace.
> 
> In particular.  The best approximation I have is to change the
> kernel to simply lookup "/dev/mqueue" and if not found fallback
> to the initial kernel instance.
> 
> I'm staring at the code as I really haven't looked at it enough
> but it sure looks like we can transform it into a proper filesystem
> with just a touch of backwards compatibility logic.
> - put the current mq_namespace in the superblock.

ok that is done. using the s_fs_info.

> - Have open/unlink lookup "/dev/mqueue" to find the filesystem
>   if nothing is found fallback to the internal mount otherwise error.

what do you mean ? loop on the mnt_namespace of current to find a 
'struct vfsmount' pointing to /dev/mqueue ?

C.

> - Possibly put the tunables in a subdirectory? and 
>   bind mount that subdirectory on top of /proc/sys/fs/mqueue/
> 
>   I'm too thrilled about the tunables but still.
>
> Are there any security holes or other oddness we would encounter
> if we did that?
> 
> If we can turn the posix mqueue stuff into an honest to goodness
> filesystem then we completely avoid nsproxy, and have something
> that is much nicer to deal with long term.
> 
> Eric