This is the case when you export the pid to the user level outside
the namespace. This case is not supposed to work at all. I know it
and there's noting we can do with it. (some more comments about this
below)
I'd like to note, that the original reason to switch the namespace off
was to help embedded people get rid of the functionality they don't
need and save the vmlinux size. Since Ingo proposed to disable the
namespace creation in a ... strange way, I noticed, that there will be
a more elegant way to do this. This was not the "fix" for cross-namespaces
communications.
Nevertheless...
Having access to the same IPCs in different pid namespaces won't work.
Having access to the same filesystem in different IPC namespaces won't work.
Having access to the same UID namespace in different VFS namespaces won't work.
Having access to the same <any> namespace in different <many others> namespace
wont' work.
That's the idea OpenVZ tried to promote when the story with "containers"
started, but most of the other participants decided that we can create
individual namespaces and step-by-step try to make them work in all the
possible combinations.
Right now we have a pid namespace, which
a) works fine in the initial namespace (by this I mean that it doesn't
introduce *new* bugs);
b) mostly works in the sub namespace. some work is to be done and it
is being done;
c) doesn't work in some ways (but not at all) when tasks communicate
across the namespace boundary, but is not going to by definition.
I'm also looking for a good solution on how to workaround the
"c" case, but I'm not agree with the statement that "the pid
namespaces are completely broken". They are not completely broken,
but there is just some work to do with the case "b" and some way
to be invented to disable the case "c".
I did not - this problem is only relevant when you try to setup the
IPC communication between processes from different namespaces, but
I have already answered this question.
If you use IPC within a single namespaces everything works just fine.
-
