[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzgPXwAsE=GQ5imEsRzfq6G9k3wjA8Esn367MPADzcPyw@mail.gmail.com>
Date: Tue, 3 Oct 2017 10:02:53 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Jürg Billeter <j@...ron.ch>,
Andrew Morton <akpm@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
Michael Kerrisk <mtk.manpages@...il.com>,
Filipe Brandenburger <filbranden@...gle.com>,
David Wilcox <davidvsthegiant@...il.com>, hansecke@...il.com,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC
On Tue, Oct 3, 2017 at 9:36 AM, Eric W. Biederman <ebiederm@...ssion.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"
> 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.
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.
Linus
Powered by blists - more mailing lists