On Sat, Oct 20, 2018 at 1:01 AM Enke Chen <enkec...@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.
