Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp741309yba; Thu, 18 Apr 2019 08:49:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqyy9kmo2ovzt0mC0FqxjmIOc+nf6QFo+GjWnTbvWu3+SZU5uKBeypYtjV0NTJHQksgLmRvq X-Received: by 2002:a17:902:778b:: with SMTP id o11mr6973645pll.333.1555602543253; Thu, 18 Apr 2019 08:49:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555602543; cv=none; d=google.com; s=arc-20160816; b=0bNzjVsUxZICHN2xe5uZ9XOLen6eOPLy3nJv1yUtQzm5HxNqTb6vqsu+tTuFhAV6rb YsnknYjSgAyUY9C/zqvAqsNl3kYQCkOFHEywoV4jRNAIgc/bpd5UlT3GmTn8kYViDB5H PYRxaF7NMoqRTCfwjHFzRe151/8B8lqCiAnvgSlrTjEhtb6L6gSlKl8Rr8NKQ/q37kPN nD6oXHyCYusnzwChxkQSfXvAiF2y8KgAn5l/R//BKLLJhNIJdPvjBh4OqMZSAsh1N9TJ XYC2vVrsxgDC2tj4Gq3SOPsx1tohbBiIqp2Y7Gjj9PjopZFPswN/elj1ZvU2/MkD+gcy q7gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=666Z1KbNWaC6YbG0wjlj1CHFXS12FVnuvEYUv3weL0E=; b=M1Ssm9dIx5Ds7snovlZnfvJiS1zxRUYpVo3hd1DTlcwyCBagAA8aOPwU2zTg5MIvUe Hwx1nxZmlk3w7kEutU2tkcjETnL/PA5mEoqvFD6S9RPsNSmyLe/digwsQIbi1YuUxfJ9 dmeVb6UVDeIYrw99nFT/PWCp5rgAiMARhKTy06e4jJA6z3/ROc3Ln5xL4epKhKPKJzjB eoQGatiWAYATETPH3ZrL3WIMZqc210CqPJ9xCc2wkjJGeMnkj8lrRucfygyzPVlxqcCn qyLsE7C7e99s0Ch5iPw/lbsfnUvdip2oTJ8m02kk0eY2fmhEbpmbOuWmtjaVFiche3y3 Tkhw== 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 144si2170723pgc.533.2019.04.18.08.48.48; Thu, 18 Apr 2019 08:49:03 -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 S2389552AbfDRPrc (ORCPT + 99 others); Thu, 18 Apr 2019 11:47:32 -0400 Received: from mout.kundenserver.de ([212.227.126.134]:36691 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387519AbfDRPrc (ORCPT ); Thu, 18 Apr 2019 11:47:32 -0400 Received: from [192.168.1.110] ([77.9.47.20]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1Mv3Ds-1gzTo12OIK-00r1CN; Thu, 18 Apr 2019 17:46:49 +0200 Subject: Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD] To: Christian Brauner Cc: Andy Lutomirski , Aleksa Sarai , Linus Torvalds , Al Viro , Jann Horn , David Howells , Linux API , LKML , "Serge E. Hallyn" , Arnd Bergmann , "Eric W. Biederman" , Kees Cook , Thomas Gleixner , Michael Kerrisk , Andrew Morton , Oleg Nesterov , Joel Fernandes , Daniel Colascione References: <20190414201436.19502-1-christian@brauner.io> <20190415195911.z7b7miwsj67ha54y@yavin> <20190417125422.bhyrmzom4kwuenwm@brauner.io> From: "Enrico Weigelt, metux IT consult" Organization: metux IT consult Message-ID: Date: Thu, 18 Apr 2019 17:46:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190417125422.bhyrmzom4kwuenwm@brauner.io> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:IYyhrkNwNtN2c6nuYeX55XOpxaneFFayWbSo+WzAChYG4HifQ9Y 2EBkdauofB47gqh6ieyX0QBtJiEXZJt6gJzKKsZ4uZMIvpaloJiMHJl+/qUWegj34i7efv2 sOl45zyKVlZeY09RnstPdYSwTuW8DzzosqhkSsG4Oc6BElqAMF+k+LhOEJaQmPdO4SR9umH LcCBrP3lBjNiZ3tbiarOg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:7ebDP8A//y0=:1vYuZJYwjSWxGy66UCRA8j kb8gEpsP5mY20IMUxfrnsjTAngLbksePjqncQYDwHwfctUyaLGVScfnrq4l/befRpA75taIxR fFBynx79+ZcSBml9oNmECqWszqwrSzFKUdbGOgThFSal58oEfJKioFMO0uT5QziowURULVszw QCYArVYdDk1uK1pYw+jfHajWc5tMxbRZP3+ZBzwXhiJoAuuU5KhJczhgLtLHxUAcDSs3/UhEE imJyaZmGmCBeucxigKTDpkvbu4iuYTUvomv+ZUhoik0sqvNg0z4ktCr8dxDxnZJ43KYeeQqWI b/d8I9zBVjYzOyJ6PKGbps5EBcKq/Ugp2soggAHDRFQsAwNa4T80CktnPcEuoQ7xc54zGE/+6 mb0+gfb8QuxeUNrvOFwsNOdHdZBgyfxuz7dukYxYOnYrEYv9FzdCiuZD3QgTK2932QyYRj6ah G0R52YwvoOBL+uzk8gyNwUk7ChsvfrandvsNx7Qu6OY8RALp0WK7uEAxM6MfC1J/fAFbY7A+V oV1HBczXmSUZm+RBghBP66JsLsGAy1WEfh++H1mE5qkpPN9csRnSt16AxiMihUB85DkPUpxUV YXM8bVYZJdHluDwTiTLVTOh6xh2Y5U2dtU4cn6DO4/FI26+no2/y41Y+takTc1zWIBwdhAQBP YvdjrkpGpAVQwYyZ0IJDsTk55Rk1586hTl0+foeRJ0lipxKxdIpQULAg4HM8vYhpFQf04By1R eB6t68VD04Lj8t8WsHpcwsuyEmPn0WyY+s9E+Ueo5qeigo3eebzUrRe0fTQ= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17.04.19 14:54, Christian Brauner wrote: >> Ah, that is a cool thing !>> I suppose that also works across namespaces ?> > Yes, it should. If you hand off the pidfd to another pidns (e.g. via SCM> credentials) for example. I thought about things like sending the pidfd via unix socket. It would be really cool if the receiving process could then control the referred process (eg. send signals), even if it's in a different pidns. >> What other things can be done via pidfd ? > > Very basic things right now and until CLONE_PIDFD is accepted (possibly > for 5.2) we won't enable any more features. > I'm not a fan of wild speculations and grand schemes that then don't > come to fruition. :) Right now it's about focussing on somewhat cleanly > covering the basics. Coming to a consensus there was hard enough. We > have no intention in making this more complex right now as it needs to > be. IMHO, it would be good if it would support all operations that now can be done via numerical PID, and w/ the permissions of the process who created that pidfd. Certainly, that would also need some lockdown mechanism, so the creating process can define what the holder of the fd can actually do. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287