Messages in this thread | | | Date | Thu, 20 Nov 2008 21:00:50 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH 1/2] protect /sbin/init from unwanted signals more |
| |
On 11/20, Eric W. Biederman wrote: > > Oleg Nesterov <oleg@redhat.com> writes: > > > On 11/19, Eric W. Biederman wrote: > >> > >> Roland McGrath <roland@redhat.com> writes: > >> > >> > With that, I wonder if the SIGNAL_UNKILLABLE checks in get_signal_to_deliver > >> > and complete_signal are needed at all. Hmm, I guess we do because this > >> > doesn't affect blocked signals, so they might be unblocked and delivered. > >> > (Note that since it doesn't affect blocked signals, this doesn't break init > >> > using sigwait if it wanted to.) > >> > >> Ah. That answers the question I had bouncing in the back of my head. > > > > Even worse. The signal can be dequeued even before unblocked by the target. > > complete_signal() can "redirect" this signal to another thread wich doesn't > > block it. > > The signal handlers should still be the same.
Yes sure. and the handler can be SIG_DFL.
In short, if we have any reason (we do have) to check sig_kernel_ignore() in get_signal_to_deliver(), then we have the same reason to check SIGNAL_UNKILLABLE too.
> >> Which reminds me. I need to retest, but I had a case where I had a trivial > > init > >> that set all signal handlers to SIG_IGN so it could ignore SIGCHLD. And not > >> all of it's children were getting reaped automagically. Do we have a bug in > >> the reparenting/reaping logic? > > > > Ah... I thought this was already fixed... shouldn't reparent_thread() > > check task_detached() after do_notify() ? like ptrace_exit() does. > > Like I said I need to retest. I was on a 2.6.26 fedora kernel base. > So if there have been recent bug fixes things may have changed.
I bet the bug is still here.
The fix should be simple, except we can't trust ptrace_reparented().
I'll send the patch, but first I'd like to do another one. Since I stopped my attempts to understand the orphaned pgrps a long ago, I hope you can review ;)
Oleg.
| |