[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081119185148.DC1D31544EB@magilla.localdomain>
Date: Wed, 19 Nov 2008 10:51:48 -0800 (PST)
From: Roland McGrath <roland@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Pavel Emelyanov <xemul@...nvz.org>,
"Serge E. Hallyn" <serue@...ibm.com>,
Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] protect /sbin/init from unwanted signals more
The effect is fine, but that seems like a kludgey way to do it.
I really don't think the sigaction case matters--certainly it will never
come up with SIGKILL. What about just this instead?
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -66,6 +66,15 @@ static int sig_ignored(struct task_struct *t, int sig)
return 0;
handler = sig_handler(t, sig);
+
+ /*
+ * For init, short-circuit any signal without a handler.
+ * We won't allow them to be delivered, so don't even queue them.
+ */
+ if (unlikely(signal->flags & SIGNAL_UNKILLABLE) &&
+ (handler == SIG_IGN || handler == SIG_DFL))
+ return 1;
+
if (!sig_handler_ignored(handler, sig))
return 0;
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.)
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists