From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752085AbdJHRsC (ORCPT ); Sun, 8 Oct 2017 13:48:02 -0400 Received: from nov-007-i584.relay.mailchannels.net ([46.232.183.138]:28406 "EHLO nov-007-i584.relay.mailchannels.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751269AbdJHRsB (ORCPT ); Sun, 8 Oct 2017 13:48:01 -0400 X-Sender-Id: novatrend|x-authuser|juerg@bitron.ch X-Sender-Id: novatrend|x-authuser|juerg@bitron.ch X-MC-Relay: Neutral X-MailChannels-SenderId: novatrend|x-authuser|juerg@bitron.ch X-MailChannels-Auth-Id: novatrend X-Language-Drop: 3dee02b25ea5a010_1507484875423_1050766523 X-MC-Loop-Signature: 1507484875423:1943695230 X-MC-Ingress-Time: 1507484875422 Message-ID: <1507484845.62760.23.camel@bitron.ch> Subject: Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC From: =?ISO-8859-1?Q?J=FCrg?= Billeter To: Oleg Nesterov Cc: "Eric W. Biederman" , Andy Lutomirski , Andrew Morton , Linus Torvalds , Michael Kerrisk , Filipe Brandenburger , David Wilcox , hansecke@gmail.com, linux-kernel@vger.kernel.org Date: Sun, 08 Oct 2017 19:47:25 +0200 In-Reply-To: <20171005162733.GA20068@redhat.com> References: <20170909094008.49983-1-j@bitron.ch> <20170929123058.48924-1-j@bitron.ch> <20171002162041.a7cefe8af71327b8becd2347@linux-foundation.org> <87o9pogbf7.fsf@xmission.com> <1507013157.2304.48.camel@bitron.ch> <878tgse1c5.fsf@xmission.com> <1507050019.19102.51.camel@bitron.ch> <20171005162733.GA20068@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-AuthUser: juerg@bitron.ch Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2017-10-05 at 18:27 +0200, Oleg Nesterov wrote: > On 10/03, Jürg Billeter wrote: > > > > My use case is to provide a way for a process to spawn a child and > > ensure that no descendants survive when that child dies. Avoiding > > runaway processes is desirable in many situations. My motivation is > > very lightweight (nested) sandboxing (every process is potentially > > sandboxed). > > > > I.e., pid namespaces would be a pretty good fit (assuming they are > > sufficiently lightweight) but CLONE_NEWPID > > sorry if this was already discussed, I didn't read this thread yet... > > if CLONE_NEWPID is not suitable for any reason. We already have > PR_SET_CHILD_SUBREAPER. Perhaps we can simply add another > PR_SET_KILL_ALL_DESCEDANTS_ON_EXIT? we can use walk_process_tree() > to send SIGKILL. Yes, this is an option. However, after the discussion in this thread I believe it would be better to drop the CAP_SYS_ADMIN requirement for CLONE_NEWPID (when no_new_privs is set) as this would avoid adding another API and code path for a similar effect. I'm interested in possible security concerns about such a change. Adding Andy Lutomirski to cc. Jürg