namespaces compatibility list

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 <[email protected]>

---

Documentation/namespaces/compatibility-list.txt new file +32 -0

new file mode 100644
index 0000000..4be4a3c
@@ -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-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

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 <[email protected]>

---

Documentation/namespaces/compatibility-list.txt new file +7 -0

new file mode 100644
index 0000000..4be4a3c
@@ -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

Documentation/namespaces/compatibility-list.txt new file +15 -0

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

Quoted 10 lines · Pavel Emelyanov

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

Quoted 8 lines

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.

Quoted 17 lines

Signed-off-by Pavel Emelyanov <[email protected]>

---

Documentation/namespaces/compatibility-list.txt new file +7 -0

new file mode 100644
index 0000000..4be4a3c
@@ -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

Documentation/namespaces/compatibility-list.txt line 17

Quoted 10 lines

Documentation/namespaces/compatibility-list.txt new file +10 -0

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

Quoted 16 lines

Documentation/namespaces/compatibility-list.txt new file +15 -0

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

Quoted 11 lines · Cedric Le Goater

Quoted 10 lines · Pavel Emelyanov

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

Quoted 3 lines

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

Quoted 15 lines · Pavel Emelyanov

Quoted 14 lines · Cedric Le Goater

Quoted 10 lines · Pavel Emelyanov

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

Quoted 4 lines

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.

C.

Quoted 20 lines · Cedric Le Goater

Quoted 19 lines · Pavel Emelyanov

Quoted 6 lines · Cedric Le Goater

Quoted 5 lines · Pavel Emelyanov

Hi guys!

As you might have seen, recently there was some spontaneous discussion about the namespaces-working-together problems.

Quoted 8 lines

Quoted 5 lines

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

Quoted 1 line

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

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.

I mean that this list cannot be encoded. But we can warn user, that some stuff will stop working if he violates some rules.

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 :)

Quoted 3 lines · Cedric Le Goater

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 :)

It doesn't work because we can't create a fresh mount namespace.

We need to create all new mounts (and deny access to the old ones) if we want to prevent all possibility of user space goof ups.

While that is easy enough to build an application to do we can't easily enforce that in the kernel. Currently this is all CAP_SYS_ADMIN so only root can do this anyway. So we can easily say don't do that then.

Clone flag consistency checking should only be used to enforce cases where the kernel side cannot support correctly. Currently the kernel has no problems with the current mix and match possibilities short of implementation deficiencies. So I do not see us addressing Ulrich's concerns with clone flags.

Eric

Quoted 15 lines · Eric W. Biederman

Quoted 3 lines · Cedric Le Goater

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 :)

It doesn't work because we can't create a fresh mount namespace.

We need to create all new mounts (and deny access to the old ones) if we want to prevent all possibility of user space goof ups.

While that is easy enough to build an application to do we can't easily enforce that in the kernel. Currently this is all CAP_SYS_ADMIN so only root can do this anyway. So we can easily say don't do that then.

Quoted 5 lines

Clone flag consistency checking should only be used to enforce cases where the kernel side cannot support correctly. Currently the kernel has no problems with the current mix and match possibilities short of implementation deficiencies. So I do not see us addressing Ulrich's concerns with clone flags.

ACK :) Since this all is CAP_SYS_ADMIN-ed we can do with just a warning.

Quoted 14 lines · Eric W. Biederman

Quoted 3 lines · Cedric Le Goater

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 :)

It doesn't work because we can't create a fresh mount namespace.

We need to create all new mounts (and deny access to the old ones) if we want to prevent all possibility of user space goof ups.

While that is easy enough to build an application to do we can't easily enforce that in the kernel. Currently this is all CAP_SYS_ADMIN so only root can do this anyway. So we can easily say don't do that then.

Quoted 5 lines

Clone flag consistency checking should only be used to enforce cases where the kernel side cannot support correctly. Currently the kernel has no problems with the current mix and match possibilities short of implementation deficiencies. So I do not see us addressing Ulrich's concerns with clone flags.

ACK :) Since this all is CAP_SYS_ADMIN-ed we can do with just a warning.

Quoted 20 lines · Pavel Emelyanov

Quoted 19 lines · Eric W. Biederman

Quoted 3 lines · Cedric Le Goater

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 :)

It doesn't work because we can't create a fresh mount namespace.

We need to create all new mounts (and deny access to the old ones) if we want to prevent all possibility of user space goof ups.

While that is easy enough to build an application to do we can't easily enforce that in the kernel. Currently this is all CAP_SYS_ADMIN so only root can do this anyway. So we can easily say don't do that then.

Clone flag consistency checking should only be used to enforce cases where the kernel side cannot support correctly. Currently the kernel has no problems with the current mix and match possibilities short of implementation deficiencies. So I do not see us addressing Ulrich's concerns with clone flags.

Quoted 1 line

ACK :) Since this all is CAP_SYS_ADMIN-ed we can do with just a warning.

Fine with me.

Let's come back to the document, then.

C.

Quoted 3 lines · Cedric Le Goater

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 :)

It doesn't work because we can't create a fresh mount namespace.

We need to create all new mounts (and deny access to the old ones) if we want to prevent all possibility of user space goof ups.

While that is easy enough to build an application to do we can't easily enforce that in the kernel. Currently this is all CAP_SYS_ADMIN so only root can do this anyway. So we can easily say don't do that then.

Clone flag consistency checking should only be used to enforce cases where the kernel side cannot support correctly. Currently the kernel has no problems with the current mix and match possibilities short of implementation deficiencies. So I do not see us addressing Ulrich's concerns with clone flags.

Eric

Documentation/namespaces/compatibility-list.txt line 32

Quoted 5 lines · Pavel Emelyanov

+2. Intentionnaly, two equal user ids in different user namespaces

Documentation/namespaces/compatibility-list.txt new file +4 -0

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

I don't know where this is going to land for a final call. But if the pid namespace has a chance of landing under CONFIG_BROKEN for the final stable release.

We seriously want to consider the user namespace for the same treatment. We all seem to agree that it is incomplete.