Thread (16 messages) flat view 16 messages, 5 authors, 2018-09-06

Re: [PATCH v2] prctl: add PR_[GS]ET_KILLABLE

From: Oleg Nesterov <oleg@redhat.com>
Date: 2018-08-03 12:14:12
Also in: lkml

On 08/03, Jürg Billeter wrote:
On Wed, 2018-08-01 at 16:19 +0200, Oleg Nesterov wrote:
quoted
On 07/31, Jürg Billeter wrote:
quoted
quoted
Could you explain your use-case? Why a shell wants to use
CLONE_NEWPID?
To guarantee that there won't be any runaway processes, i.e., ensure
that no descendants (background helper daemons or misbehaving
processes) survive when the child process is terminated.
We already have PR_SET_CHILD_SUBREAPER.

Perhaps we can finally add PR_KILL_MY_DESCENDANTS_ON_EXIT? This was already
discussed some time ago, but I can't find the previous discussion... Simple
to implement.
This would definitely be an option. You mentioned it last October in
the PR_SET_PDEATHSIG_PROC discussion¹. However, as PID namespaces
already exist and appear to be a good fit for the most part,
Sure, if CLONE_NEWPID fits your needs you can use it,
I think it
makes sense to just add the missing pieces to PID namespaces instead of
duplicating part of the PID namespace functionality.
Again, I am not arguing with your change.

PR_KILL_MY_DESCENDANTS_ON_EXIT can make sense just like PR_SET_CHILD_SUBREAPER
even if PID namespace functionality implies both. Simply because CLONE_NEWPID
is not necessarily the best tool, if nothing else you do not necessarily want
the pid isolation.
Also, based on Eric's comment in that other discussion about
no_new_privs not being allowed to increase the attack surface,
PR_KILL_MY_DESCENDANTS_ON_EXIT might require CAP_SYS_ADMIN as well (due
to setuid children).
No, no, the exiting parent should simply do group_send_sig_info(SIGKILL)
for every descendant and rely on check_kill_permission().

OK, lets forget it for now.

Oleg.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help