User: Password:
Subscribe / Log in / New account

Process IDs in a multi-namespace world

Process IDs in a multi-namespace world

Posted Nov 6, 2007 20:44 UTC (Tue) by iq-0 (subscriber, #36655)
Parent article: Process IDs in a multi-namespace world

It's an interesting puzzle. I'm still pondering what the direct consequence would be if the
pid number would be completely de-coupled from the container logic (pid numbers are unique
within the system and don't try to magically encode container membership).
The only theoretical problem I currently see is that creating new processes will show you how
many new processes were created in the whole system (not just this container), but is that
really that bad? Or is it just a part of containers not being "invisible"? Because containers
simply aren't invisible and this one little piece of more evidence that they aren't isn't
really that big a deal.
But somebody will hopefull proof me wrong and point out that this really is a big deal ;-)

(Log in to post comments)

Process IDs in a multi-namespace world

Posted Nov 6, 2007 20:52 UTC (Tue) by martinfick (subscriber, #4455) [Link]

One problem with this is that you can't have the 'root-parent' for each namespace with a PID
of 1 then.  This could be faked so that this process has a unique global id but appears to
system tools (other processes) as PID 1.  I don't think it needs to think of itself as PID 1,
does it?

I'm not sure of if there are other problems?

Process IDs in a multi-namespace world

Posted Nov 6, 2007 21:36 UTC (Tue) by iq-0 (subscriber, #36655) [Link]

Good point, I had overlooked that one. There are some programs that check for pid 1 (I thought
bash did that, and init too). From a pure technical standpoint it shouldn't matter too much
but I can imagine tons of code checking if their parent is 1 (daemonize checks eg.)

Process IDs in a multi-namespace world

Posted Nov 8, 2007 18:43 UTC (Thu) by brouhaha (subscriber, #1698) [Link]

I can't think of any good reason for any program (other than perhaps init itself and telinit)
to care what PID init has, and even those could be changed to use a better mechansim.

In particular, whether a program runs as a daemon or not should definitely NOT be determined
by the PPID.

The PID should be viewed as an entirely opaque data type, and shouldn't need namespaces.

Process IDs in a multi-namespace world

Posted Nov 7, 2007 18:27 UTC (Wed) by mrjk (subscriber, #48482) [Link]

A global pid is context information that probably shouldn't be shared across "context boxes".
You could possibly figure out what pid a "targeted" process is by knowing about when it 
started and what processes started before and after. This would be useful in an attack 
breaking confinement. I know this is all theoretical, and may not even be possible, but if 
you can design it out you don't have to seriously think about it. 

Why should processes in one box have any knowledge of the processes running in another 
that don't explicitly announce themselves? If you are relying on this then you are really 
in the same context (process namespace) anyway. It doesn't matter that the containers 
are visible or not, this is one of the points in having containers with namespaces in 
the first place, I would think.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds