Re: [PATCH] kernel/signal: Signal-based pre-coredump notification
From: Jann Horn
Date: Mon Oct 22 2018 - 11:41:05 EST
On Sat, Oct 20, 2018 at 1:01 AM Enke Chen <enkechen@xxxxxxxxx> 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):
> 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.