From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Jürg Billeter" <j@bitron.ch>, "Oleg Nesterov" <oleg@redhat.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Michael Kerrisk" <mtk.manpages@gmail.com>,
"Filipe Brandenburger" <filbranden@google.com>,
"David Wilcox" <davidvsthegiant@gmail.com>,
"Adam H . Peterson" <alphaetapi@hotmail.com>,
hansecke@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC
Date: Mon, 02 Oct 2017 22:25:32 -0500 [thread overview]
Message-ID: <87o9pogbf7.fsf@xmission.com> (raw)
In-Reply-To: <20171002162041.a7cefe8af71327b8becd2347@linux-foundation.org> (Andrew Morton's message of "Mon, 2 Oct 2017 16:20:41 -0700")
Andrew Morton <akpm@linux-foundation.org> writes:
> On Fri, 29 Sep 2017 14:30:58 +0200 Jürg Billeter <j@bitron.ch> 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 https://marc.info/?l=linux-kernel&m=117621804801689
>> and https://bugzilla.kernel.org/show_bug.cgi?id=43300
>
> 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
effect.
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.
Eric
next prev parent reply other threads:[~2017-10-03 3:25 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-09 9:40 [PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC Jürg Billeter
2017-09-12 17:05 ` Oleg Nesterov
2017-09-12 18:54 ` Jürg Billeter
2017-09-13 17:11 ` Oleg Nesterov
2017-09-13 17:26 ` Jürg Billeter
2017-09-13 17:48 ` Oleg Nesterov
2017-09-29 12:30 ` [RESEND PATCH] " Jürg Billeter
2017-10-02 23:20 ` Andrew Morton
2017-10-03 3:25 ` Eric W. Biederman [this message]
2017-10-03 6:45 ` Jürg Billeter
2017-10-03 14:46 ` Eric W. Biederman
2017-10-03 16:10 ` Linus Torvalds
2017-10-03 16:36 ` Eric W. Biederman
2017-10-03 17:02 ` Linus Torvalds
2017-10-03 19:30 ` Eric W. Biederman
2017-10-03 20:02 ` Linus Torvalds
2017-10-03 20:32 ` Eric W. Biederman
2017-10-03 17:00 ` Jürg Billeter
2017-10-03 17:40 ` Eric W. Biederman
2017-10-03 17:47 ` Jürg Billeter
2017-10-03 19:05 ` Eric W. Biederman
2017-10-05 16:27 ` Oleg Nesterov
2017-10-08 17:47 ` Jürg Billeter
2017-10-09 16:32 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o9pogbf7.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=alphaetapi@hotmail.com \
--cc=davidvsthegiant@gmail.com \
--cc=filbranden@google.com \
--cc=hansecke@gmail.com \
--cc=j@bitron.ch \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=oleg@redhat.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.