[PATCH] userns: Allow the unprivileged users to mount mqueue fs

[PATCH] userns: Allow the unprivileged users to mount mqueue fs

[Gao feng]

This patch allow the unprivileged user to mount mqueuefs in
user ns.

If two userns share the same ipcns,the files in mqueue fs
should be seen in both these two userns.

If the userns has its own ipcns,it has its own mqueue fs too.
ipcns has already done this job well.

Signed-off-by: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
---
 ipc/mqueue.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index 71a3ca1..023c986 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -1383,6 +1383,7 @@ static struct file_system_type mqueue_fs_type = {
 	.name = "mqueue",
 	.mount = mqueue_mount,
 	.kill_sb = kill_litter_super,
+	.fs_flags = FS_USERNS_MOUNT,
 };
 
 int mq_init_ns(struct ipc_namespace *ns)
-- 
1.7.11.7

Re: [PATCH] userns: Allow the unprivileged users to mount mqueue fs

[Eric W. Biederman]

Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> writes:

> This patch allow the unprivileged user to mount mqueuefs in
> user ns.
>
> If two userns share the same ipcns,the files in mqueue fs
> should be seen in both these two userns.
>
> If the userns has its own ipcns,it has its own mqueue fs too.
> ipcns has already done this job well.

I am a little dense.  When does userspace actually mount a mqueuefs?
My impression was that user space never needed to mount and actually
never could mount a mqueuefs.  MS_NO_USER isn't set so mounting a
mqueuefs is possible but when does it happen and why?

I am trying to think through the logic here and I think this is safe
but since I don't understand why we would mount an mqueue fs I am
having trouble verifying that there are no silly reasons why this might
be a bad idea.

But from what I can tell so far this seems like a good patch.

Eric


> Signed-off-by: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
> ---
>  ipc/mqueue.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> index 71a3ca1..023c986 100644
> --- a/ipc/mqueue.c
> +++ b/ipc/mqueue.c
> @@ -1383,6 +1383,7 @@ static struct file_system_type mqueue_fs_type = {
>  	.name = "mqueue",
>  	.mount = mqueue_mount,
>  	.kill_sb = kill_litter_super,
> +	.fs_flags = FS_USERNS_MOUNT,
>  };
>  
>  int mq_init_ns(struct ipc_namespace *ns)

Re: [PATCH] userns: Allow the unprivileged users to mount mqueue fs

[Gao feng]

On 2013/01/28 11:43, Eric W. Biederman wrote:
> Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> writes:
> 
>> This patch allow the unprivileged user to mount mqueuefs in
>> user ns.
>>
>> If two userns share the same ipcns,the files in mqueue fs
>> should be seen in both these two userns.
>>
>> If the userns has its own ipcns,it has its own mqueue fs too.
>> ipcns has already done this job well.
> 
> I am a little dense.  When does userspace actually mount a mqueuefs?
> My impression was that user space never needed to mount and actually
> never could mount a mqueuefs.  MS_NO_USER isn't set so mounting a
> mqueuefs is possible but when does it happen and why?
> 

Actually the files which representative messgae queue in mqueuefs contains
some informations,such as QSIZE,NOTIFY,SIGNO,NOTIFY_PID.

My workstation is Fedora 17,mqueuefs is mounted on /dev/mqueue by default.
So I think at lest this patch is needed by some people.

Thanks!
Gao

> I am trying to think through the logic here and I think this is safe
> but since I don't understand why we would mount an mqueue fs I am
> having trouble verifying that there are no silly reasons why this might
> be a bad idea.
> 
> But from what I can tell so far this seems like a good patch.
> 
> Eric
> 
> 
>> Signed-off-by: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
>> ---
>>  ipc/mqueue.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
>> index 71a3ca1..023c986 100644
>> --- a/ipc/mqueue.c
>> +++ b/ipc/mqueue.c
>> @@ -1383,6 +1383,7 @@ static struct file_system_type mqueue_fs_type = {
>>  	.name = "mqueue",
>>  	.mount = mqueue_mount,
>>  	.kill_sb = kill_litter_super,
>> +	.fs_flags = FS_USERNS_MOUNT,
>>  };
>>  
>>  int mq_init_ns(struct ipc_namespace *ns)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [PATCH] userns: Allow the unprivileged users to mount mqueue fs

[Eric W. Biederman]

Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> writes:

> On 2013/01/28 11:43, Eric W. Biederman wrote:
>> Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> writes:
>> 
>>> This patch allow the unprivileged user to mount mqueuefs in
>>> user ns.
>>>
>>> If two userns share the same ipcns,the files in mqueue fs
>>> should be seen in both these two userns.
>>>
>>> If the userns has its own ipcns,it has its own mqueue fs too.
>>> ipcns has already done this job well.
>> 
>> I am a little dense.  When does userspace actually mount a mqueuefs?
>> My impression was that user space never needed to mount and actually
>> never could mount a mqueuefs.  MS_NO_USER isn't set so mounting a
>> mqueuefs is possible but when does it happen and why?
>> 
>
> Actually the files which representative messgae queue in mqueuefs contains
> some informations,such as QSIZE,NOTIFY,SIGNO,NOTIFY_PID.
>
> My workstation is Fedora 17,mqueuefs is mounted on /dev/mqueue by default.
> So I think at lest this patch is needed by some people.

I have just confirmed that the most you can do in a mounted mqueue fs is
to create files message queues.

Given that these filesystems exist anyway I don't see a problem.

Applied thanks.

Eric