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

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

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Tue, Oct 3, 2017 at 9:36 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>>
>> *Scratches head*
>> pdeath_signal is cleared during exec if bprm->cap_elevated.
>
> It's not cleared if we are *releasing* capabilities, which is exactly
> what might cause a "we can no longer send a signal"

*Doh*  Now I see where you are coming from.

>> is_setid is set if the uid != eid or gid != egid.
>
> Again, that may be exactly what changes - the original process may
> have uid != euid, and now we're going from an "we still had a root
> uid/suid" to "dropping everything to euid".
>
> IOW, we're _dropping_ capabilities, not adding them. Maybe we don't
> want to allow signaling the original parent any more.

We never signal the orignal parent.  We signal the child that
requested the pdeath_signal when the original parent dies.

The permission check is:
   Does the parent have permission to signal the child that requested
   the signal.

So the child dropping permissions won't change the result of that
permission check one iota.

The parent dropping permissions may change the result of that permission
check.

I care about this case because we already have the pdeath_signal and the
permission check doesn't make any sense to me, and appears not to be at all
useful.

Plus it is the only caller of group_send_sig_info outside of
kernel/signal.c so I think the kernel would be more maintainable if we
could simplify this piece of code.

> That said, as mentioned, I actually don't think it's a real problem.
> The real problem is entirely conceptual: yet more complexity in an
> area that we've already had problems in before.

>From the conversation so far it does appear we can do better.

Eric