On 02/19, Eric W. Biederman wrote: > > Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx> writes: > > > From: Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx> > > Date: Wed, 24 Dec 2008 14:14:18 -0800 > > Subject: [PATCH 7/7][v8] SI_USER: Masquerade si_pid when crossing pid ns > > boundary > > > > When sending a signal to a descendant namespace, set ->si_pid to 0 since > > the sender does not have a pid in the receiver's namespace. > > > > Note: > > - If rt_sigqueueinfo() sets si_code to SI_USER when sending a > > signal across a pid namespace boundary, the value in ->si_pid > > will be cleared to 0. > > > > Changelog[v5]: > > - (Oleg Nesterov) Address both sys_kill() and sys_tkill() cases > > in send_signal() to simplify code (this drops patch 7/7 from > > earlier version of patchset). > > > > Signed-off-by: Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx> > > --- > > kernel/signal.c | 2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/kernel/signal.c b/kernel/signal.c > > index c94355b..a416d77 100644 > > --- a/kernel/signal.c > > +++ b/kernel/signal.c > > @@ -883,6 +883,8 @@ static int __send_signal(int sig, struct siginfo *info, > > struct task_struct *t, > > break; > > default: > > copy_siginfo(&q->info, info); > > + if (from_ancestor_ns) > > + q->info.si_pid = 0; > > This is wrong. siginfo is a union and you need to inspect > code to see if si_pid is present in the current union. SI_FROMUSER() == T, unless we have more (hopefully not) in-kernel users which send SI_FROMUSER() signals, .si_pid must be valid? kill_pid_info_as_uid() was the only known sender of SI_FROMUSER signal, it was converted to use __send_signal(from_ancestor_ns => 0). Oleg. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
