linux-kernel - Re: signals: Bug or manpage inconsistency?

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 30 May 2017 10:19:32 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        linux-man@...r.kernel.org, libc-alpha <libc-alpha@...rceware.org>
Subject: Re: signals: Bug or manpage inconsistency?

On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov <oleg@...hat.com> wrote:
>
> I can't comment, I never tried to understand the rationality behind the current
> behaviour. But at least the sending path should never drop a blocked SIG_DFL
> signal, there is no other way to ensure you won't miss a signal during exec.

Note that both SIG_DFL _and_ SIG_IGN are possible after exec, so if
you don't want to drop particular signals to the new process (which
may then add its own handler and want them), using the signal blocked
mask is the rigth thing to do for both of them,

SIG_IGN doesn't mean "ignore signal forever". It means "ignore signals
right now", and I think that our current signal blocking semantics are
likely the correct ones, exactly because it means "when you start
blocking signals, the kernel will not drop them".

There is no difference wrt SIG_DFL and SIG_IGN in this sense.

> Obviously this is a user-visible change and it can break something. Say, an
> application does sigwaitinfo(SIGCHLD) and SIGCHLD is ignored (SIG_IGN), this
> will no longer work.

That's an interesting special case. Yes, SIG_IGN actually has magical
properties wrt SIGCHLD. It basically means the opposite of ignoring
it, it's an "implicit signal handler".  So I could imagine people
using SIG_IGN to avoid the signal handler, but then block SIG_CHLD and
using sigwait() for it.

That sounds nonportable as hell, but I could imagine people doing it
because it happens to work.

So again, I really wouldn't want to change existing semantics unless
there is a big real reason for it. Our current semantics are not
wrong.

                Linus