[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200421112606.ay4cck2dphguqazb@wittgenstein>
Date: Tue, 21 Apr 2020 13:26:06 +0200
From: Christian Brauner <christian.brauner@...ntu.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Linux Containers <containers@...ts.linux-foundation.org>,
Christof Meerwald <cmeerw@...erw.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] signal: Avoid corrupting si_pid and si_uid in
do_notify_parent
On Tue, Apr 21, 2020 at 01:11:40PM +0200, Oleg Nesterov wrote:
> Sorry Christian, I don't understand...
In my original mail, it was really just a clarification question. I
said the patch is correct from looking at the codepaths. :) I was just
trying to see whether there was a potential corner-case we're missing
where "force" could be _validly_ true.
>
> > because child subreapers can't come from outside the pid namespace. If
> > they could you could create a scenario where the signal is generated
> > from a sibling pid namespace in which case it would be correctly set to
> > true.
>
> not sure I understand, but probably the answer is "yes"...
(This is really purely academic now since it isn't possible, but for
pure amusement assume that a child subreaper could cross namespace
boundaries (which they don't). A marks itself as a subreaper and creates
a new process B in a new pid namespace <pidnsB>, process B setnses into
<pidnsC> which is a sibling pid namespace, B clones a new proces in
<pidnsC> which is now a full member of <pidnsC>, B dies and C is
reparented to A, B exits and then you'd be getting a sigchld from a pid
in a pid namespace in which you have no pid nr.)
Powered by blists - more mailing lists