lkml.org 
[lkml]   [2018]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] kernel/signal: Signal-based pre-coredump notification
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.

\
 
 \ /
  Last update: 2018-10-22 17:41    [W:0.099 / U:0.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site