Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp2632535ybb; Sat, 30 Mar 2019 09:41:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqxbWRSaMWJb9ochKM5IofxLcObjwlRzmJ2vCkkZDwQHSgUpSaEMLv53tooeQgxypy94XtkP X-Received: by 2002:a17:902:2927:: with SMTP id g36mr27314691plb.57.1553964071026; Sat, 30 Mar 2019 09:41:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553964071; cv=none; d=google.com; s=arc-20160816; b=IktaD1NMZw2y8QYRi7VtoRRbGjlaQc1RaVl/T5bGA+fQsDZIQKNmX4ZzYSERczrxqL vDPDnd9R5mBQ9iFPEIw2xQ1gwBa8EoQR03194XHjlELYCqtokIykS2arbOEjZaqGPo71 2979USNhVIQ8N+5QfuykyCsywSDZ6Xim2azp8k0BkVSMGsi0+HjChvL20VpTJ1YuIKC+ nsjJY60DhWf9d/P5QI9DTdDmkMKGgjqVUmjWuwVaHxVhODe0kPzN0cMV34NgFLJc9Huv MY0WVaZZ9u7ZSgzJq+H2mGDDKKq62JXEgi7BSwQsHuqF8o4mv63W1uOu8wOdfdF5vrCv vkHQ== 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:dkim-signature; bh=jjm0qai9ZYPiT6TdWCxaI36M0QNMMCcOH+KsLm1g4yk=; b=AVSicRc448ny7dwI0BvHcKx3sXkp0ba8CC7xfOC2JzYnlSLbf6qO3XqLkBIhzqaKjQ O/b7XclsHtypWKtMdkuAuHSjVCjDTM4RM5x23TnaN19g7nePQdS3Hn7jRHpePyvT+ey8 evM+mF0jb5pIL+0V1K+RdigTs8CnNpzuuMK6ewEBquCl8eQhJYkxqwrEpEEW991tvgmo tn8kZBf2ubc4Q89tlKR6G02ewRKof70CDjnVktTNb1qRvifWZk1Lr6uaOXJMVnhRX3Yo +6YxH6MOKMhCULz8X6vRLFkHS5XRigs/OiHGlzXW+sdEzRk7JIFmfCBgsT+8l9ueERfT O7aA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brauner.io header.s=google header.b=SBAbLJ+y; 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 r17si4835668pgh.311.2019.03.30.09.40.55; Sat, 30 Mar 2019 09:41:11 -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=@brauner.io header.s=google header.b=SBAbLJ+y; 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 S1730730AbfC3QjA (ORCPT + 99 others); Sat, 30 Mar 2019 12:39:00 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:45902 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730395AbfC3Qi7 (ORCPT ); Sat, 30 Mar 2019 12:38:59 -0400 Received: by mail-ed1-f65.google.com with SMTP id m16so4560071edd.12 for ; Sat, 30 Mar 2019 09:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jjm0qai9ZYPiT6TdWCxaI36M0QNMMCcOH+KsLm1g4yk=; b=SBAbLJ+yrT3ryIK8UHLD8e8YOy5e0RUB5qoIpTlBgTCKRnKhaWgXL1opeOGSFccP1+ Rr+c5AGBH96NUOy+P5hPzupqRZwaBGNsPgk6Gemwv1DeT7woLhWA0211e0SyjGBunmkv B/LcHtd96AYr1f6m06qZau9xqoc45UoeqNJXrGWSc4cGFsNZCOLtdIVSHTMqNo0IlWLf MZrBcH6oFRTw2XgEA0Icu5Kp7f+v88CaXuKK4rKNvr2wI8hFiasqtIW6OIJaKD2t/MNd VqkMLvPNkrTb7JhylLzuHWXb9zFFQOLaqfYkH3FewhL0ID/zUpmTScMvrauYoZ5BznXB L2Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jjm0qai9ZYPiT6TdWCxaI36M0QNMMCcOH+KsLm1g4yk=; b=Ex/11anN9l2ozGn/BCiR8tIQ1Ihx7bm/hPQCCpdOzwpPdPVhQ5c3XOrY+seqK3feOf LBcovnYleojLcKKshJzgTk5289hhvvNa8JawIcPYnPy5sO/lDdbGAgbDjcsOU24Ib7Qk c0nm7nMVcfxZoW+6UQ9NY/rfjzFjMh0IDZNZO+H+oHiRYiWadyCkgFRQxqDGG4uIVF03 Kr1kGlameHqAIYyLItZUC9bn1yaP7M/O3FqXg759ponAfCYt9JHeiiNlIrDgWfWq44lZ 9efHSLZo/66Og53bSa6LWmzcoohFeFQHSsWiOTb4kz5w8VFOpBalWjoOPbdzBv//AVN4 wnxA== X-Gm-Message-State: APjAAAW4zqa529xhdGJ18gvxO/x4gZ/O/2y5dwHdCq3q8wx6Fj+3EjUu Tu5x3VV6HaUke2dmXHJonqgYFqR69Pc= X-Received: by 2002:a50:97d0:: with SMTP id f16mr34880013edb.287.1553963937408; Sat, 30 Mar 2019 09:38:57 -0700 (PDT) Received: from brauner.io ([2a02:8109:b6bf:d24a:b136:35b0:7c8c:280a]) by smtp.gmail.com with ESMTPSA id z35sm1613912edd.81.2019.03.30.09.38.56 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sat, 30 Mar 2019 09:38:56 -0700 (PDT) Date: Sat, 30 Mar 2019 17:38:55 +0100 From: Christian Brauner To: Daniel Colascione Cc: Linus Torvalds , 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 Subject: Re: [PATCH v2 0/5] pid: add pidfd_open() Message-ID: <20190330163854.t67m2h6m3hmshqtg@brauner.io> References: <20190329155425.26059-1-christian@brauner.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 30, 2019 at 09:34:02AM -0700, Daniel Colascione wrote: > On Sat, Mar 30, 2019 at 9:24 AM Linus Torvalds > wrote: > > > > On Sat, Mar 30, 2019 at 9:19 AM Christian Brauner wrote: > > > > > > From pure API perspective that's all I care about: independence of procfs. > > > Once we have pidfd_open() we can cleanly signal threads etc. > > > > But "independence from procfs" means that you damn well don't then do > > "oh, now I have a pidfd, I want to turn it into a /proc fd and then > > munge around there". > > > > So I'm literally saying that it had better really *be* independent > > from /proc. It is the standalone version, but it's most definitely > > also the version that doesn't then give you secret access to /proc. > > Just to be clear, I'm not proposing granting secret access to procfs, > and as far as I can see, nobody else is either. We've been talking > about making it easier to avoid races when you happen to want a pidfd > and a procfs fd that point to the same process, not granting access > that you didn't have before. If you'd rather not connect procfs and > pidfds, we can take this functionality off the table. This is dead! Nothing like this will make it through this tree. I have no intention of endangering pidfd_send_signal(). Christian