Re: [PATCH] kernel/signal: Signal-based pre-coredump notification

[Jann Horn <jannh@google.com>]

On Sat, Oct 20, 2018 at 1:01 AM Enke Chen <enkechen@cisco.com> wrote:
> Regarding the security considerations, it seems simpler and more secure to
> just clear the "pre-coredump signal" cross execve(2), and let the new program
> decide for itself.  What do you think?

I don't have a problem with these semantics.

I could imagine someone being unhappy about the theoretical race
window if they want to perform an in-place reexecution of a running
service, but I don't know whether anyone actually cares about that.

> Changes to prctl(2):
>
> DESCRIPTION
>
>        PR_SET_PREDUMP_SIG (since Linux 4.20.x)
>               This allows the calling process to receive a signal (arg2,
>               if nonzero) from a child process prior to the coredump of
>               the child process. arg2 must be SIGUSR1, or SIGUSR2, or
>               SIGCHLD, or 0 (for clear).
>
>               When SIGCHLD is specified, the signal code is set to
>               CLD_PREDUMP in such an SIGCHLD signal.
>
>               The value of the pre-coredump signal is cleared across
>               execve(2), or for the child of a fork(2).
>
>        PR_GET_PREDUMP_SIG (since Linux 4.20.x)
>               Return the current value of the pre-coredump signal for the
>               calling process, in the location pointed to by (int *) arg2.