Re: [patch] PID namespace design bug, workaround

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Pavel Emelyanov wrote:
>> So is "everything else", you mentioned, covered with the problems
>> above?
> 
> No, it's not.  If you'd read the mail carefully you'd notice that the
> use of PIDs especially in robust futexes is part of the API and that it
> simply isn't acceptable to say "don't do that".  A robust mutex can be
> stored in any file and as long as two processes have access to the same
> file (or they can pass each other shared memory) the underlying futex
> functionality simply must work.

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)

> This whole approach to allow switching on and off each of the namespaces
> is just wrong.  Do it all or nothing, at least for the problematic ones
> like NEWPID.  Having access to the same filesystem but using separate
> PID namespaces is simply not going to work.

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

> You also brush completely over the SysV IPC issue.

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.

> And I doubt that I spent enough time thinking about all this to arrive
> at the more subtle problems.  I don't think especially the PID namespace
> is ready at all at this time.
> 
> - --
> ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> 
> iD4DBQFHK0N42ijCOnn/RHQRAkPyAJiDR9ZEPUbCdEa2xk+Te80B7avDAJ4mgy7v
> jgtZG129yBUGBrpQ8fbn7w==
> =ho0Z
> -----END PGP SIGNATURE-----
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux