Re: [PATCH] userns: Allow the unprivileged users to mount mqueue fs
Gao feng writes: > On 2013/01/28 11:43, Eric W. Biederman wrote: >> Gao feng 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.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
On 2013/01/28 11:43, Eric W. Biederman wrote:
> Gao feng 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
>> ---
>> 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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.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
Gao feng 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
> ---
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] userns: Allow the unprivileged users to mount mqueue fs
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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] userns: Allow the unprivileged users to mount mqueue fs
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 gaof...@cn.fujitsu.com
---
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.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
Gao feng gaof...@cn.fujitsu.com 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 gaof...@cn.fujitsu.com
---
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 majord...@vger.kernel.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
On 2013/01/28 11:43, Eric W. Biederman wrote:
Gao feng gaof...@cn.fujitsu.com 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 gaof...@cn.fujitsu.com
---
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.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
Gao feng gaof...@cn.fujitsu.com writes: On 2013/01/28 11:43, Eric W. Biederman wrote: Gao feng gaof...@cn.fujitsu.com 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
