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 <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• References:
  • [patch] PID namespace design bug, workaround
    • From: Ingo Molnar <[email protected]>
  • Re: [patch] PID namespace design bug, workaround
    • From: Pavel Emelyanov <[email protected]>
  • Re: [patch] PID namespace design bug, workaround
    • From: Ulrich Drepper <[email protected]>
  • Re: [patch] PID namespace design bug, workaround
    • From: Pavel Emelyanov <[email protected]>
  • Re: [patch] PID namespace design bug, workaround
    • From: Ulrich Drepper <[email protected]>
  • Re: [patch] PID namespace design bug, workaround
    • From: Pavel Emelyanov <[email protected]>
  • Re: [patch] PID namespace design bug, workaround
    • From: Andrew Morton <[email protected]>
  • Re: [patch] PID namespace design bug, workaround
    • From: Dave Hansen <[email protected]>
  • Re: [patch] PID namespace design bug, workaround
    • From: Linus Torvalds <[email protected]>
  • Re: [patch] PID namespace design bug, workaround
    • From: Ingo Molnar <[email protected]>
  • Re: [patch] PID namespace design bug, workaround
    • From: Linus Torvalds <[email protected]>
  • Re: [patch] PID namespace design bug, workaround
    • From: Arjan van de Ven <[email protected]>

• Prev by Date: Re: "Fix ATAPI transfer lengths" causes CD writing regression
• Next by Date: Re: drive side 80-wire cable detection failed
• Previous by thread: Re: [patch] PID namespace design bug, workaround
• Next by thread: Re: [patch] PID namespaces
• Index(es):
  • Date
  • Thread

[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]