Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2300119yba; Mon, 15 Apr 2019 08:51:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqz8ENXBif+sBDNL7dtDVDPs1/c85JVw1Y0KK96OxDxNqF0Y8uHS8O2gfkG+/fSyTwxKVGSJ X-Received: by 2002:a17:902:e48f:: with SMTP id cj15mr75720059plb.256.1555343488071; Mon, 15 Apr 2019 08:51:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555343488; cv=none; d=google.com; s=arc-20160816; b=dLnbxWXttJkznvAloeYJOaHYXkcZEjEIhdcEYrT58eRnnq6hPDd3qZqHqcsS3vXvBb cdxsKh6NimCpCGjceQHJ4QT8v5g6eC6huMztsXaMImeEadS1Ato1vJFZDAbT+WVoFVVw bPciax5OFo3jJNzao00CoCiIHxTLichIifT9bJ+bHrlJBhHd9QVogu+bgyqkyx3lFXhn hurK3goisVvYIBL0ffuuMG8lreMRJoQ6DefIVtQ6UV8o+GgMp/zPhLV77F39fOwSBmzT 4p65FftBcjnWzE6inKphU6V76Fc6mrSUa64BzeF6mVOtqorOUoQf8MZB11FL30Dm/zhk RTnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=kU6QnomxWMTKLdWA+NnKAneFipWCZUaS/wRCsmWDuTs=; b=xrCe9Fr7AoAjfSIhJbmJaGMNI2n3HaIlb4Q+zqfhEhRqqaoXQ1neD0gnT1w3heIb0M fhSvVhNpPGpKoFV4OwvMpAQfqDGDh3XN8KBSWIf22F5bqA0uGNz3oCyXFC31zE5cHx49 h64S8mfg6EEVx6ZFVllyVlBD38ApjuigsSCzT+gRCBDDEtC/FUQrlyYe1TNaJ9qYTVk4 aaQM28keoEfMoSUBf1tWC517csL7OEgQO5Oh3ACoN6mxaH7tfSsED11qNwIjHDa9/8m5 ik17MYUIxh3P8dvl97xS2G1HBTNuKUGc6ZVeIZ85LO9Em+Fjn4PD18GfaD0QUuBWpLcC 6C5w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e3si29850505pgc.98.2019.04.15.08.51.10; Mon, 15 Apr 2019 08:51:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727455AbfDOPug (ORCPT + 99 others); Mon, 15 Apr 2019 11:50:36 -0400 Received: from mail.hallyn.com ([178.63.66.53]:40858 "EHLO mail.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726034AbfDOPug (ORCPT ); Mon, 15 Apr 2019 11:50:36 -0400 Received: by mail.hallyn.com (Postfix, from userid 1001) id 69909978; Mon, 15 Apr 2019 10:50:34 -0500 (CDT) Date: Mon, 15 Apr 2019 10:50:34 -0500 From: "Serge E. Hallyn" To: "Enrico Weigelt, metux IT consult" Cc: Christian Brauner , torvalds@linux-foundation.org, viro@zeniv.linux.org.uk, jannh@google.com, dhowells@redhat.com, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, serge@hallyn.com, luto@kernel.org, arnd@arndb.de, ebiederm@xmission.com, keescook@chromium.org, tglx@linutronix.de, mtk.manpages@gmail.com, akpm@linux-foundation.org, oleg@redhat.com, cyphar@cyphar.com, joel@joelfernandes.org, dancol@google.com Subject: Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD] Message-ID: <20190415155034.GA25351@mail.hallyn.com> References: <20190414201436.19502-1-christian@brauner.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 15, 2019 at 12:08:09PM +0200, Enrico Weigelt, metux IT consult wrote: > On 14.04.19 22:14, Christian Brauner wrote: > > Hi folks, > > > This patchset makes it possible to retrieve pid file descriptors at > > process creation time by introducing the new flag CLONE_PIDFD to the > > clone() system call as previously discussed. > > Sorry, for highjacking this thread, but I'm curious on what things to > consider when introducing new CLONE_* flags. > > The reason I'm asking is: > > I'm working on implementing plan9-like fs namespaces, where unprivileged > processes can change their own namespace at will. For that, certain Is there any place where we can see previous discussion about this? > traditional unix'ish things have to be disabled, most notably suid. If you have to disable suid anyway, then is there any reason why the existing ability to do this in a private user namespace, with only your own uid mapped (which you can do without any privilege) does not suffice? That was actually one of the main design goals of user namespaces, to be able to clone(CLONE_NEWUSER), map your current uid, then clone(CLONE_NEWNS) and bind mount at will. > As forbidding suid can be helpful in other scenarios, too, I thought > about making this its own feature. Doing that switch on clone() seems > a nice place for that, IMHO. > > As there might be potentially even more CLONE_* flags in the future, > and the bitmask size is limited, this raises the question on how to > proceed with those flag additions in the future. > > What's your thoughts on that ? > > > --mtx > > -- > Enrico Weigelt, metux IT consult > Free software and Linux embedded engineering > info@metux.net -- +49-151-27565287