From: Roland McGrath <roland@redhat.com>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: Oleg Nesterov <oleg@redhat.com>,
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
Andrew Morton <akpm@osdl.org>,
daniel@hozac.com, Containers <containers@lists.osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 7/7][v8] SI_USER: Masquerade si_pid when crossing pid ns boundary
Date: Thu, 19 Feb 2009 15:51:59 -0800 (PST) [thread overview]
Message-ID: <20090219235159.6A542FC3BE@magilla.sf.frob.com> (raw)
In-Reply-To: Eric W. Biederman's message of Thursday, 19 February 2009 15:21:34 -0800 <m1fxiaxbb5.fsf@fess.ebiederm.org>
> Suppose I have 3 processes in a process group in three separate pid
> namespaces.
>
> Looking from the init pid namespace I have:
> pid pgrp ppid
> 10 10 1
> 11 10 10
> 12 10 11
>
> Looking from the pid namespace of pid 11 I have:
> pid pgrp ppid
> 0 0 0
> 1 0 0
> 2 0 1
>
> Looking from the pid namespace of pid 12 I have:
> pid pgrp ppid
> 0 0 0
> 0 0 0
> 1 0 0
>
> So if the process with pid 12 in the initial pid namespace
> sends to process group 0.
There is no "process group 0". 0 means "the sender's pgrp".
One possibility is that perhaps what people really want the pid_ns to mean
is that "the sender's pgrp" in the view of the sender does not include any
processes outside its pid_ns scope. That would be consistent with the
behavior of kill (kill_something_info) on -1; it's described as "all
processes", but in fact means "all processes within my pid_ns scope".
What I mean to describe there is changing kill_something_info, so that
e.g. killpg() inside the NS would affect only the NS init itself but e.g.
^Z (effectively an implicit killpg() that's always from the global NS)
would also go to that init's "mother" pgrp in the outer NS.
Another possibility is to decide that's just not worth having at all, and
CLONE_NEWNS should just implicitly reset pgrp to self. That is simple.
But perhaps today someone has a script running a pid_ns-world whose init is
gracefully killed by ^C of the whole script and we wouldn't want to break
that if it is actually useful now.
> pid 10 should see si_pid 12.
> pid 11 should see si_pid 2.
We indeed have this problem if we think it's useful to continue to have
a concept of pgrp for the sub-init that can see outside its own NS.
> Neither should see si_pid 0, as from_ancestor_ns will not be true.
Perhaps replace from_ancestor_ns with struct pid_namespace *sender_ns?
(I don't know if there was already a can of worms with such an idea before.)
Then si_pid could be translated as appropriate for each recipient.
(Or perhaps just struct pid *sender and reset si_pid from that.)
Thanks,
Roland
next prev parent reply other threads:[~2009-02-19 23:53 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-19 3:02 [PATCH 0/7][v8] Container-init signal semantics Sukadev Bhattiprolu
2009-02-19 3:05 ` [PATCH 1/7][v8] Remove 'handler' parameter to tracehook functions Sukadev Bhattiprolu
2009-02-19 3:05 ` [PATCH 2/7][v8] Protect init from unwanted signals more Sukadev Bhattiprolu
2009-02-19 3:06 ` [PATCH 3/7][v8] Add from_ancestor_ns parameter to send_signal() Sukadev Bhattiprolu
2009-02-19 3:06 ` [PATCH 4/7][v8] Protect cinit from unblocked SIG_DFL signals Sukadev Bhattiprolu
2009-02-19 3:07 ` [PATCH 5/7][v8] zap_pid_ns_process() should use force_sig() Sukadev Bhattiprolu
2009-02-19 18:59 ` Oleg Nesterov
2009-02-19 20:26 ` Sukadev Bhattiprolu
2009-02-19 3:07 ` [PATCH 6/7][v8] Protect cinit from blocked fatal signals Sukadev Bhattiprolu
2009-02-19 3:07 ` [PATCH 7/7][v8] SI_USER: Masquerade si_pid when crossing pid ns boundary Sukadev Bhattiprolu
2009-02-19 16:11 ` Eric W. Biederman
2009-02-19 18:51 ` Oleg Nesterov
2009-02-19 22:18 ` Eric W. Biederman
2009-02-19 22:31 ` Oleg Nesterov
2009-02-19 23:21 ` Eric W. Biederman
2009-02-19 23:51 ` Roland McGrath [this message]
2009-02-20 0:35 ` Eric W. Biederman
2009-02-20 1:06 ` Roland McGrath
2009-02-20 2:12 ` Eric W. Biederman
2009-02-20 3:10 ` Roland McGrath
2009-02-20 4:05 ` Eric W. Biederman
2009-02-20 0:28 ` Oleg Nesterov
2009-02-20 1:16 ` Eric W. Biederman
2009-02-19 14:59 ` [PATCH 0/7][v8] Container-init signal semantics Daniel Lezcano
2009-03-07 19:04 ` Sukadev Bhattiprolu
2009-03-07 19:43 ` Daniel Lezcano
2009-03-07 19:51 ` Greg Kurz
2009-03-07 19:59 ` Daniel Lezcano
2009-02-19 20:53 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090219235159.6A542FC3BE@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=akpm@osdl.org \
--cc=containers@lists.osdl.org \
--cc=daniel@hozac.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=sukadev@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®