On Wed, 2018-08-01 at 16:19 +0200, Oleg Nesterov wrote: > On 07/31, Jürg Billeter wrote: > > > > > 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, I think it makes sense to just add the missing pieces to PID namespaces instead of duplicating part of the PID namespace functionality. 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). In which case the only potential benefit would be that it still allows the child to kill arbitrary processes, as far as I can tell. > > And to prevent children from killing their ancestors. > > OK, this is the only reason for CLONE_NEWPID which I can understand so far. > Not that I understand why this is that useful ;) The overall goal is increasing isolation between (some) child processes and the rest of the system. Isolation from runaway processes and isolation from signals are independent aspects and it could be useful to control them independently. However, I also expect it to be common that both are wanted at the same time. Jürg ¹ https://lkml.org/lkml/2017/10/5/546 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
