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@xxxxxxxxxx> > > --- > > 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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers