Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

[ebiederm@xmission.com (Eric W. Biederman)]

Jürg Billeter <j@bitron.ch> writes:

> On Mon, 2017-10-02 at 22:25 -0500, Eric W. Biederman wrote:
>> 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.
>
> Depending on how you look at it, one could also argue that the dying
> parent sends the signal. However, I'm fine with dropping the permission
> check in v2. I'll also send a patch to change this for the existing
> pdeath_signal.

The process that requests the signal be sent is the process that is
receiving the signal.  I can see a theoretical need for a permission
check in there somewhere (especially as this persists over fork).

That is what matters for a permission check.

I tried fixing this once along with a bunch of other changes, and
apparently I did not do it obviously enough.  So I think this needs to
happen but let's make it very clear.

>> 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.
>
> I agree that inheritance across fork is mainly useful for SIGKILL.
> While non-SIGKILL users could clear the setting after fork(), another
> option would be to allow the caller to specify whether the setting
> should be inherited using prctl arg3.

>
> This would allow both, the exact process-based equivalent to
> pdeath_signal (no inheritance) as well as the interesting SIGKILL case
> for killing a process tree. Does this sound sensible? I'd be happy to
> add this to v2.

Possibly.

There is a general need to find out about the death of other processes,
if you are not the parent of the process.   I would be inclined to call
it waitfd.  Something that you give a pid.  It performs a permission
check and the pid becomes readable when the process dies.  With poll
working on the fd, and the fd returning wstatus of the dead child.

Support SIGIO on the fd and you have a signal delivery mechanism,
if you want it.

For the kill all children when the parent dies the mechanism you are
proposing is escapable.  We already have an inescapable version of it
with init in a pid namespace.  We already have an escapable version of
it with orphaned process groups and SIGHUP.

So I would really appreciate a very clear use case for what we are
building here.  As it appears the killing of children can already be
done another way, and that the waiting for the parent can be done better
another way.

At the end of the day I would prefer to support something that has a
good solid definition and a clear use case.

I may be missing something and there is a good reason to extend pdeath
signal, but I don't see it right now.

Eric