Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp987387yba; Sun, 31 Mar 2019 19:14:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqym4Ut3YOvysKlaKkzSeTiYubONdPWJPg/CcRY70cyQEGqf24LFXv3WFMqXGDaao6+cttwU X-Received: by 2002:a63:751d:: with SMTP id q29mr22507035pgc.215.1554084872912; Sun, 31 Mar 2019 19:14:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554084872; cv=none; d=google.com; s=arc-20160816; b=GH+wwTyUzwQukP0HaVmHIiP4/Sydoi5lcIsK18lTkKotXLJNMHFI55EML0CzjkyUZH rm+llF4+aQ8XRcgKuC7Ve9exizqBhbGiTcf8okQqU+GLf+luSrzVU5O52s1GeZCce6mb ouTzPGzvQ8w0NmYIN7n/klWbnD0Lo7/PFU3vqo7wfBw0ZWJv/gH5x+NOWhHXiU9P6DZl Q/aj0t7sE59pA/JXG2MgJxiCpDZa9+JQCzMmmI9lB+5ksGKOVpsDP3H3O4YHiKGtdTdp /7XtbNa3I2uzJc80Zik0oPkQz+D1zdk6zEcS7z95QRd8bxtotVoyeF3eKQGLcTiKAT1B Qghw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=CxXB4SWfc6S3NBwSbbwXW5l/4r4k5EPDkipFxiKya6c=; b=g/WGKHsXifrveRD6U+Va2x70tnUEGuVczgdpPMdPC/ySvz/PN4O2LvnVWPbpOtSJDw F5UL6DYXu4tSo11c/342oe5YoiNeaoo5BCW47rxqEMchhd7QZnUg1fVfWE+o/eUtnEev jW5TAR0cm7MjVeuw5s7fsNOXN5YaWW6kShCanrFXTzrF5hGx32IMDBv8UVkFfUB50Yf7 tqNxbmb9MhTuGe/QD+HgPM9+lWNgBBJFXmsUOuwrJpYjopP68BkIToxmmN3GOozuHBMC eE7BUqmtOwiVChYT0qJvkQ5WK+yzCLac35ZUS+8cPjn7s6fpyN/lFxZotmoHtUiiRWhr hnwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=lR7IiVPB; 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 t7si7557382plo.163.2019.03.31.19.14.17; Sun, 31 Mar 2019 19:14:32 -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; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=lR7IiVPB; 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 S1731383AbfDACNm (ORCPT + 99 others); Sun, 31 Mar 2019 22:13:42 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:43844 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726985AbfDACNm (ORCPT ); Sun, 31 Mar 2019 22:13:42 -0400 Received: by mail-pf1-f194.google.com with SMTP id c8so3725309pfd.10 for ; Sun, 31 Mar 2019 19:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CxXB4SWfc6S3NBwSbbwXW5l/4r4k5EPDkipFxiKya6c=; b=lR7IiVPBqeZIboLIDb6wST1HkE5i0AHVGX5X3AxyBf/JR4nAKUOcNtSxJKiGHwUKwI UYbnSesKhpHZxWtHpBpoNBxyMHtKom3qvKSFKKOMlmNbpOx0V7KMVMWNXESo+4G1ocM8 S+Vp2F0Rv71KLGzD48YfXv5eUejz7TTULI19hlBjVbmfZ/cpP3AL5czn3R57h+881uwD DzAAhaMCZNMdztkafjlQXH8MtrRakn9hwxxzCkZaZF2lmlN0TSqonA8pOeSvK+S0KYNq sgQmGdr73b+Yi46HQXxVqBqKoVrQ498sLtVeKILmT94CRMHfHnjEMwYwyqsdhqaqqOo7 HKMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CxXB4SWfc6S3NBwSbbwXW5l/4r4k5EPDkipFxiKya6c=; b=U8LO8EotBGBAGtsElcIvHq8BxQJipX4WYyGAW/2Ho8MMiqAXcYennD1etdRcW8+qph L8d+HY4QI5rcQp2KSc4Fk29/MfSzJMdT5Q+lfBamz3hIi+TDNLXEMZjJFjjiXs9h+/cf 30qhpyXmJ525L4w3cQYXwuFHhIERGrr2wyrBGf9h1GTEmrzYBOx3iv7pn5YXUOIjb+FX VimWkH8Xw89U3FeS3RKjMrSKVsi4z274q1TcUUCet4YJdHw3TGj/YwK9ktwqGrHuEmJN IVX2XxJxslwpsvC/Ryeokgu4QCXBrzClmBowBleEN+TICKpCKyDreafpOf5GjrWNrP53 eFBg== X-Gm-Message-State: APjAAAXTsUoSxk6crr4pTpmBKK8EM5AMkPqZd63S8tMwfGkuZ7Ad5A2C P5SREnlo+KeAm6xZOEBa2MasQw== X-Received: by 2002:a63:3190:: with SMTP id x138mr51205623pgx.273.1554084821322; Sun, 31 Mar 2019 19:13:41 -0700 (PDT) Received: from ?IPv6:2600:100e:b13e:a3af:389b:29a:6d03:f8bf? ([2600:100e:b13e:a3af:389b:29a:6d03:f8bf]) by smtp.gmail.com with ESMTPSA id 75sm14804796pfr.55.2019.03.31.19.13.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Mar 2019 19:13:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v2 0/5] pid: add pidfd_open() From: Andy Lutomirski X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Sun, 31 Mar 2019 20:13:38 -0600 Cc: Christian Brauner , Daniel Colascione , Jann Horn , Andrew Lutomirski , David Howells , "Serge E. Hallyn" , Linux API , Linux List Kernel Mailing , Arnd Bergmann , "Eric W. Biederman" , Konstantin Khlebnikov , Kees Cook , Alexey Dobriyan , Thomas Gleixner , Michael Kerrisk-manpages , Jonathan Kowalski , "Dmitry V. Levin" , Andrew Morton , Oleg Nesterov , Nagarathnam Muthusamy , Aleksa Sarai , Al Viro , Joel Fernandes Content-Transfer-Encoding: quoted-printable Message-Id: <18C7FCB9-2CBA-4237-94BB-9C4395A2106B@amacapital.net> References: <20190329155425.26059-1-christian@brauner.io> <20190330171215.3yrfxwodstmgzmxy@brauner.io> <132107F4-F56B-4D6E-9E00-A6F7C092E6BD@amacapital.net> <20190331211041.vht7dnqg4e4bilr2@brauner.io> To: Linus Torvalds Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Mar 31, 2019, at 3:17 PM, Linus Torvalds wrote: >=20 >> On Sun, Mar 31, 2019 at 2:10 PM Christian Brauner w= rote: >>=20 >> I don't think that we want or can make them equivalent since that would >> mean we depend on procfs. >=20 > Sure we can. >=20 > If /proc is enabled, then you always do that dance YOU ALREADY WROTE > THE CODE FOR to do the stupid ioctl. >=20 > And if /procfs isn't enabled, then you don't do that. >=20 > Ta-daa. Done. No stupid ioctl, and now /proc and pidfd_open() return > the same damn thing. >=20 > And guess what? If /proc isn't enabled, then obviously pidfd_open() > gives you the /proc-less thing, but at least there is no crazy "two > different file descriptors for the same thing" situation, because then > the /proc one doesn't exist. >=20 I wish we could do this, and, in a clean design, it would be a no-brainer. B= ut /proc has too much baggage. Just to mention two such things, there=E2=80= =99s =E2=80=9Cnet=E2=80=9D and =E2=80=9C../sys=E2=80=9D. This crud is why w= e have all kinds of crazy rules that prevent programs in sandboxes from maki= ng a new mounts and mounting /proc in it. If we make it possible to clone a= new process and this access /proc without having /proc mounted, we=E2=80=99= ll open up a big can of worms. Maybe we could have a sanitized view of /proc and make a pidfd be a director= y fd pointing at that.=