Messages in this thread | | | Date | Sat, 3 Nov 2007 17:21:33 -0700 (PDT) | From | david@lang ... | Subject | Re: [patch] PID namespace design bug, workaround |
| |
On Sat, 3 Nov 2007, Arjan van de Ven wrote:
> On Sat, 3 Nov 2007 15:40:48 -0700 (PDT) > Linus Torvalds <torvalds@linux-foundation.org> wrote: > >> I don't understand how you can call this a "PID namespace design >> bug", when it clearly has nothing what-so-ever to do with pid >> namespaces, and everything to do with the *futexes* that blithely >> assume that pid's are unique and that made it part of the >> user-visible interface. >> >> OF COURSE any pid namespace design will always break such >> assumptions, but that's not because of any PID namespace bugs. It's >> what the whole *point* of PID namespaces are. If you use pid's >> (instead of some opaque cookies), you will not be able to use such >> things across pid-separation. > > well... kind of. > THere are 2 things around pid namespaces: which pids you can see/touch > (in proc or signals or otherwise), and the non-uniqueness. > > For containers you clearly want the first part... but... is there a > strong reason to not just *not* create duplicate pids even across > namespaces? there's no rule in posix or anything similar to fd's afaik > concerning which pids we can hand out... so we could just make then > unique globally but just with limited visibility....
two problems that I can think of
1. the container people would like to eventually have the ability to migrate containers from one system to another (or to suspend a container) in this sort of case trying to fit the allocated PIDs from the container into a running system is a problem if PIDs are not allowed to overlap.
2. it seems to me that there is porobably a latent security issue in having a global PID namespace with just limited visability. the types of bugs that may let you affect a process seem easier to make if the only protection is visability rather then complete seperation.
David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |