Home » Mailing lists » Devel » namespaces compatibility list
namespaces compatibility list [message #22856] |
Tue, 06 November 2007 10:51 |
Pavel Emelianov
Messages: 1149 Registered: September 2006
|
Senior Member |
|
|
Hi guys!
As you might have seen, recently there was some spontaneous
discussion about the namespaces-working-together problems.
Ted T'so proposed to create some document that describes what
problems user may have when he/she creates some new namespace,
but keeps others shared. I like this idea, so here's the draft
with the problems I currently have in mind and can describe
somewhat audibly - the "namespaces compatibility list".
The Documentation/namespaces/ dir is about to contain more
docs about the namespaces stuff (e.g. I'm going to prepare
a doc about the pid namespaces, maybe Serge will want to
write something about the user namespaces development, Eric
may want to put some notes about the netns API and so on),
but currently there will be only one file.
What would you say about it?
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/Documentation/namespaces/compatibility-list.txt b/Documentation/namespaces/compatibility-list.txt
new file mode 100644
index 0000000..4be4a3c
--- /dev/null
+++ b/Documentation/namespaces/compatibility-list.txt
@@ -0,0 +1,32 @@
+ Namespaces compatibility list
+
+This document contains the information about the problems user
+may have when creating tasks living in different namespaces.
+
+Here's the summary. This matrix shows the known problems, that
+occur when tasks share some namespace (the columns) while living
+in different other namespaces (the raws):
+
+ UTS IPC VFS PID User Net
+UTS
+IPC 1
+VFS
+PID 1 1
+User 2
+Net
+
+1. Both the IPC and the PID namespaces provide IDs to address
+ object inside the kernel. E.g. semaphore with ipcid or
+ process group with pid.
+
+ In both cases, tasks shouldn't try telling this id to some
+ other task living in different namespace vid shared filesystem
+ or IPC shmem/message. The fact is that this ID is only valid
+ within the namespace it was obtained in and may refer to some
+ other object in another namespace.
+
+2. Intentionnaly, two equal user ids in different user namespaces
+ should not be equal from the VFS point of view. In other
+ words, user 10 in one user namespace shouldn't have the same
+ access permissions to files, beloging to user 10 in another
+ namespace. But currently this is not so.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
Re: namespaces compatibility list [message #22859 is a reply to message #22856] |
Tue, 06 November 2007 12:33 |
dev
Messages: 1693 Registered: September 2005 Location: Moscow
|
Senior Member |
|
|
imho very good idea and we'll have more and more docs there...
(the only issue I see - it would be nice to have cgroups docs in the same place,
though cgroups are not about namespaces directly.)
Acked-By: Kirill Korotaev <dev@sw.ru>
Pavel Emelyanov wrote:
> Hi guys!
>
> As you might have seen, recently there was some spontaneous
> discussion about the namespaces-working-together problems.
>
> Ted T'so proposed to create some document that describes what
> problems user may have when he/she creates some new namespace,
> but keeps others shared. I like this idea, so here's the draft
> with the problems I currently have in mind and can describe
> somewhat audibly - the "namespaces compatibility list".
>
> The Documentation/namespaces/ dir is about to contain more
> docs about the namespaces stuff (e.g. I'm going to prepare
> a doc about the pid namespaces, maybe Serge will want to
> write something about the user namespaces development, Eric
> may want to put some notes about the netns API and so on),
> but currently there will be only one file.
>
> What would you say about it?
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> ---
>
> diff --git a/Documentation/namespaces/compatibility-list.txt b/Documentation/namespaces/compatibility-list.txt
> new file mode 100644
> index 0000000..4be4a3c
> --- /dev/null
> +++ b/Documentation/namespaces/compatibility-list.txt
> @@ -0,0 +1,32 @@
> + Namespaces compatibility list
> +
> +This document contains the information about the problems user
> +may have when creating tasks living in different namespaces.
> +
> +Here's the summary. This matrix shows the known problems, that
> +occur when tasks share some namespace (the columns) while living
> +in different other namespaces (the raws):
> +
> + UTS IPC VFS PID User Net
> +UTS
> +IPC 1
> +VFS
> +PID 1 1
> +User 2
> +Net
> +
> +1. Both the IPC and the PID namespaces provide IDs to address
> + object inside the kernel. E.g. semaphore with ipcid or
> + process group with pid.
> +
> + In both cases, tasks shouldn't try telling this id to some
> + other task living in different namespace vid shared filesystem
> + or IPC shmem/message. The fact is that this ID is only valid
> + within the namespace it was obtained in and may refer to some
> + other object in another namespace.
> +
> +2. Intentionnaly, two equal user ids in different user namespaces
> + should not be equal from the VFS point of view. In other
> + words, user 10 in one user namespace shouldn't have the same
> + access permissions to files, beloging to user 10 in another
> + namespace. But currently this is not so.
>
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
>
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
Re: namespaces compatibility list [message #22860 is a reply to message #22856] |
Tue, 06 November 2007 12:54 |
Cedric Le Goater
Messages: 443 Registered: February 2006
|
Senior Member |
|
|
Pavel Emelyanov wrote:
> Hi guys!
>
> As you might have seen, recently there was some spontaneous
> discussion about the namespaces-working-together problems.
>
> Ted T'so proposed to create some document that describes what
> problems user may have when he/she creates some new namespace,
> but keeps others shared. I like this idea, so here's the draft
> with the problems I currently have in mind and can describe
> somewhat audibly - the "namespaces compatibility list".
that compatibility list could be encoded in the way we check
the clone flags in copy_process() and unshare(). It would
also be good to have it as a comment somewhere in kernel/fork.c
> The Documentation/namespaces/ dir is about to contain more
> docs about the namespaces stuff (e.g. I'm going to prepare
> a doc about the pid namespaces, maybe Serge will want to
> write something about the user namespaces development, Eric
> may want to put some notes about the netns API and so on),
> but currently there will be only one file.
>
> What would you say about it?
well, as this is user space issues, I'd say that we should
help building a good man page. What's in Documentation/
could help to do that but I don't trust documentation when
it's maintained in 2 places.
So a check_flags() routine for namespaces with all the required
comments would probably be more helpful for the manpage
maintainer.
I was thinking of merging some clone flags together also and
keep only 3, NS, PID and NET.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> ---
>
> diff --git a/Documentation/namespaces/compatibility-list.txt b/Documentation/namespaces/compatibility-list.txt
> new file mode 100644
> index 0000000..4be4a3c
> --- /dev/null
> +++ b/Documentation/namespaces/compatibility-list.txt
> @@ -0,0 +1,32 @@
> + Namespaces compatibility list
> +
> +This document contains the information about the problems user
> +may have when creating tasks living in different namespaces.
> +
> +Here's the summary. This matrix shows the known problems, that
> +occur when tasks share some namespace (the columns) while living
> +in different other namespaces (the raws):
> +
> + UTS IPC VFS PID User Net
> +UTS
> +IPC 1
> +VFS
> +PID 1 1
> +User 2
> +Net
> +
funny, I had just started doing :
depends on VFS PID IPC NET UTS MQ
VFS *
PID * *
IPC * *
NET * *
UTS *
MQ * * ? * *
I kept VFS out for the moment.
I would rather build a matrix giving the dependencies. nop ? which
is a way to enforce the clone flags.
C.
> +1. Both the IPC and the PID namespaces provide IDs to address
> + object inside the kernel. E.g. semaphore with ipcid or
> + process group with pid.
> +
> + In both cases, tasks shouldn't try telling this id to some
> + other task living in different namespace vid shared filesystem
> + or IPC shmem/message. The fact is that this ID is only valid
> + within the namespace it was obtained in and may refer to some
> + other object in another namespace.
> +
> +2. Intentionnaly, two equal user ids in different user namespaces
> + should not be equal from the VFS point of view. In other
> + words, user 10 in one user namespace shouldn't have the same
> + access permissions to files, beloging to user 10 in another
> + namespace. But currently this is not so.
>
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
Re: namespaces compatibility list [message #22861 is a reply to message #22860] |
Tue, 06 November 2007 13:00 |
Pavel Emelianov
Messages: 1149 Registered: September 2006
|
Senior Member |
|
|
Cedric Le Goater wrote:
> Pavel Emelyanov wrote:
>> Hi guys!
>>
>> As you might have seen, recently there was some spontaneous
>> discussion about the namespaces-working-together problems.
>>
>> Ted T'so proposed to create some document that describes what
>> problems user may have when he/she creates some new namespace,
>> but keeps others shared. I like this idea, so here's the draft
>> with the problems I currently have in mind and can describe
>> somewhat audibly - the "namespaces compatibility list".
>
> that compatibility list could be encoded in the way we check
> the clone flags in copy_process() and unshare(). It would
> also be good to have it as a comment somewhere in kernel/fork.c
How can we insure, that a new task will not share the files
with its parent to address the PID namespaces vs VFS namespaces
interaction? There's no way to do it. We can only keep them in
one IPC namespace...
>> The Documentation/namespaces/ dir is about to contain more
>> docs about the namespaces stuff (e.g. I'm going to prepare
>> a doc about the pid namespaces, maybe Serge will want to
>> write something about the user namespaces development, Eric
>> may want to put some notes about the netns API and so on),
>> but currently there will be only one file.
>>
>> What would you say about it?
>
> well, as this is user space issues, I'd say that we should
> help building a good man page. What's in Documentation/
> could help to do that but I don't trust documentation when
> it's maintained in 2 places.
>
> So a check_flags() routine for namespaces with all the required
> comments would probably be more helpful for the manpage
> maintainer.
>
> I was thinking of merging some clone flags together also and
> keep only 3, NS, PID and NET.
>
>> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>>
>> ---
>>
>> diff --git a/Documentation/namespaces/compatibility-list.txt b/Documentation/namespaces/compatibility-list.txt
>> new file mode 100644
>> index 0000000..4be4a3c
>> --- /dev/null
>> +++ b/Documentation/namespaces/compatibility-list.txt
>> @@ -0,0 +1,32 @@
>> + Namespaces compatibility list
>> +
>> +This document contains the information about the problems user
>> +may have when creating tasks living in different namespaces.
>> +
>> +Here's the summary. This matrix shows the known problems, that
>> +occur when tasks share some namespace (the columns) while living
>> +in different other namespaces (the raws):
>> +
>> + UTS IPC VFS PID User Net
>> +UTS
>> +IPC 1
>> +VFS
>> +PID 1 1
>> +User 2
>> +Net
>> +
>
> funny, I had just started doing :
>
> depends on VFS PID IPC NET UTS MQ
> VFS *
> PID * *
> IPC * *
> NET * *
> UTS *
> MQ * * ? * *
>
> I kept VFS out for the moment.
>
> I would rather build a matrix giving the dependencies. nop ? which
> is a way to enforce the clone flags.
>
> C.
>
>
>> +1. Both the IPC and the PID namespaces provide IDs to address
>> + object inside the kernel. E.g. semaphore with ipcid or
>> + process group with pid.
>> +
>> + In both cases, tasks shouldn't try telling this id to some
>> + other task living in different namespace vid shared filesystem
>> + or IPC shmem/message. The fact is that this ID is only valid
>> + within the namespace it was obtained in and may refer to some
>> + other object in another namespace.
>> +
>> +2. Intentionnaly, two equal user ids in different user namespaces
>> + should not be equal from the VFS point of view. In other
>> + words, user 10 in one user namespace shouldn't have the same
>> + access permissions to files, beloging to user 10 in another
>> + namespace. But currently this is not so.
>>
>
>
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
Re: namespaces compatibility list [message #22876 is a reply to message #22873] |
Tue, 06 November 2007 16:46 |
Cedric Le Goater
Messages: 443 Registered: February 2006
|
Senior Member |
|
|
Pavel Emelyanov wrote:
> Cedric Le Goater wrote:
>> Pavel Emelyanov wrote:
>>> Cedric Le Goater wrote:
>>>> Pavel Emelyanov wrote:
>>>>> Hi guys!
>>>>>
>>>>> As you might have seen, recently there was some spontaneous
>>>>> discussion about the namespaces-working-together problems.
>>>>>
>>>>> Ted T'so proposed to create some document that describes what
>>>>> problems user may have when he/she creates some new namespace,
>>>>> but keeps others shared. I like this idea, so here's the draft
>>>>> with the problems I currently have in mind and can describe
>>>>> somewhat audibly - the "namespaces compatibility list".
>>>> that compatibility list could be encoded in the way we check
>>>> the clone flags in copy_process() and unshare(). It would
>>>> also be good to have it as a comment somewhere in kernel/fork.c
>>> How can we insure, that a new task will not share the files
>>> with its parent to address the PID namespaces vs VFS namespaces
>>> interaction? There's no way to do it. We can only keep them in
>>> one IPC namespace...
>> ? I'm not sure I understand you.
>
> As far as I understand, you propose the check for the clone flags
> in the copy_process()/sys_unshare() and return -EINVAL for the cases
> we consider to be unsafe. E.g. when a user wants to clone new pid
> namespace, he must clone the ipc namespace as well.
yes.
> But my point is that this check is not enough - user may kill himself
> by cloning a pid namespace and sharing the pids via the filesystem
> (like with the example with futexes) and there's no way to check for
> this situation in the copy_process()/sys_unchare.
right. I think we can address Ulrich concerns first because we have
a solution for it (which looks like unsharing all namespaces at once,
here comes back the container object story :)
> I mean that this list cannot be encoded. But we can warn user, that
> some stuff will stop working if he violates some rules.
and then do that for the futexes, which are a real difficult case.
thanks,
C.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
|
|
|
|
Re: namespaces compatibility list [message #22914 is a reply to message #22856] |
Wed, 07 November 2007 13:49 |
Cedric Le Goater
Messages: 443 Registered: February 2006
|
Senior Member |
|
|
There's also a Documentation/unshare.txt. Should we update it also ?
> --- /dev/null
> +++ b/Documentation/namespaces/compatibility-list.txt
> @@ -0,0 +1,32 @@
> + Namespaces compatibility list
> +
> +This document contains the information about the problems user
> +may have when creating tasks living in different namespaces.
> +
> +Here's the summary. This matrix shows the known problems, that
> +occur when tasks share some namespace (the columns) while living
> +in different other namespaces (the raws):
s/raws/rows/
> +
> + UTS IPC VFS PID User Net
> +UTS
> +IPC 1
> +VFS
> +PID 1 1
> +User 2
> +Net
This is dense but I can't think of a better representation.
> +1. Both the IPC and the PID namespaces provide IDs to address
> + object inside the kernel. E.g. semaphore with ipcid or
> + process group with pid.
> +
> + In both cases, tasks shouldn't try telling this id to some
s/telling/exposing/ ?
> + other task living in different namespace vid shared filesystem
.. in a different namespace via a shared filesystem
> + or IPC shmem/message. The fact is that this ID is only valid
> + within the namespace it was obtained in and may refer to some
> + other object in another namespace.
> +
> +2. Intentionnaly, two equal user ids in different user namespaces
> + should not be equal from the VFS point of view. In other
> + words, user 10 in one user namespace shouldn't have the same
> + access permissions to files, beloging to user 10 in another
> + namespace. But currently this is not so.
>
>
Thanks Pavel,
C.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
Goto Forum:
Current Time: Sat Oct 19 22:24:48 GMT 2024
Total time taken to generate the page: 0.04945 seconds
|