linux-kernel - Re: [PATCH] ____call_usermodehelper: don't flush

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 27 Feb 2007 12:22:04 +0300
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ____call_usermodehelper: don't flush_signals()

On 02/27, Rusty Russell wrote:
>
> On Tue, 2007-02-27 at 00:53 +0300, Oleg Nesterov wrote:
> > ____call_usermodehelper() has no reason for flush_signals(). It is a fresh
> > forked process which is going to exec a user-space application or exit on
> > failure.
> 
> And the flush_signal_handlers() call?

Well... flush_old_exec() calls flush_signal_handlers(force_default = 0),
this is not enough. We don't want to start user-space application with
SIGKILL ignored (yes, parent doesn't ignores it currently).

> Your patch looks correct; this code was presumably lying around from
> before someone (I?) adapted this code to use kthread.

Thanks! What I can't understand is why kthread/daemonize block all signals.
This doesn't look good to me. This can't prevent signal delivery, this only
blocks signal_wake_up(). We can even set SIGNAL_GROUP_EXIT for the kernel
thread. Of course, only root can do that, but isn't it better to just ignore
all signals instead of blocking them?

Note that we can't free the memory if we send a signal to (for example)
khelper.

Oleg.

-
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/