From: Eric W. Biederman
Date: Mon Oct 02 2017 - 23:25:57 EST

Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes:

> On Fri, 29 Sep 2017 14:30:58 +0200 JÃrg Billeter <j@xxxxxxxxx> wrote:
>> PR_SET_PDEATHSIG sets a parent death signal that the calling process
>> will get when its parent thread dies, even when the result of getppid()
>> doesn't change because the calling process is reparented to a different
>> thread in the same parent process. When managing multiple processes, a
>> process-based parent death signal is much more useful. E.g., to avoid
>> stray child processes.
>> PR_SET_PDEATHSIG_PROC sets a process-based death signal. Unlike
>> PR_SET_PDEATHSIG, this is inherited across fork to allow killing a whole
>> subtree without race conditions.
>> This can be used for sandboxing when combined with a seccomp filter.
>> There have been previous attempts to support this by changing the
>> behavior of PR_SET_PDEATHSIG. However, that would break existing
>> applications. See
>> and
> Are Eric and Oleg OK with this?
> A prctl manpage update will be needed, please (cc linux-api).

It makes for an interesting way of killing a process tree. The domino

I believe the rational for adding a new prctl.

The code where it calls group_send_sig_info is buggy for pdeath_signal.
And it no less buggy for this new case. There is no point to check
permissions when sending a signal to yourself. Especially this signal
gets cleared during exec with a change of permissions.

I would recommend using:
do_send_sig_info(p->signal->pdeath_signal_proc, SEND_SIG_NOINFO, p, true);

Perhaps with a comment saying that no permission check is needed when
sending a signal to yourself.

I don't know what I think about inherit over fork, and the whole tree
killing thing. Except when the signal is SIGKILL I don't know if that
code does what is intended. So I am a little leary of it.