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.