Messages in this thread | | | Date | Tue, 21 Apr 2020 13:26:06 +0200 | From | Christian Brauner <> | 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.)
| |