From: Jann Horn <jannh@google.com> To: Daniel Colascione <dancol@google.com> Cc: Jonathan Kowalski <bl0pbl33p@gmail.com>, Joel Fernandes <joel@joelfernandes.org>, Christian Brauner <christian@brauner.io>, Konstantin Khlebnikov <khlebnikov@yandex-team.ru>, Andy Lutomirski <luto@kernel.org>, David Howells <dhowells@redhat.com>, "Serge E. Hallyn" <serge@hallyn.com>, "Eric W. Biederman" <ebiederm@xmission.com>, Linux API <linux-api@vger.kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, Kees Cook <keescook@chromium.org>, Alexey Dobriyan <adobriyan@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Michael Kerrisk-manpages <mtk.manpages@gmail.com>, "Dmitry V. Levin" <ldv@altlinux.org>, Andrew Morton <akpm@linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>, Aleksa Sarai <cyphar@cyphar.com>, Al Viro <viro@zeniv.linux.org.uk> Subject: Re: [PATCH 0/4] pid: add pidctl() Date: Mon, 25 Mar 2019 21:34:00 +0100 [thread overview] Message-ID: <CAG48ez1ZVKgwfQDYT1k4pB4-8Y8Ywv12dabh5KFFxtKmT-e7Cw@mail.gmail.com> (raw) In-Reply-To: <CAKOZueuYMKdkt8BoSj1+p7=mpe2PA8r7xT5QiF6q3cTK+6HsAA@mail.gmail.com> On Mon, Mar 25, 2019 at 9:15 PM Daniel Colascione <dancol@google.com> wrote: > On Mon, Mar 25, 2019 at 12:42 PM Jonathan Kowalski <bl0pbl33p@gmail.com> wrote: > > On Mon, Mar 25, 2019 at 6:57 PM Daniel Colascione <dancol@google.com> wrote: [...] > > Yes, but everything in /proc is not equivalent to an attribute, or an > > option, and depending on its configuration, you may not want to allow > > processes to even be able to see /proc for any PIDs other than those > > running as their own user (hidepid). This means, even if this new > > system call is added, to respect hidepid, it must, depending on if > > /proc is mounted (and what hidepid is set to, and what gid= is set > > to), return EPERM, because then there is a discrepancy between how the > > two entrypoints to acquire a process handle do access control. > > That's why I proposed that this translation mechanism accept a procfs > root directory --- so you'd specify *which* procfs you want and let > the kernel apply whatever hidepid access restrictions it wants. [...] > > > and 2) it's > > > "fail unsafe": IMHO, most users in practice will skip the line marked > > > "LIVENESS CHECK", and as a result, their code will appear to work but > > > contain subtle race conditions. An explicit interface to translate > > > from a (PIDFD, PROCFS_ROOT) tuple to a /proc/pid directory file > > > descriptor would be both more efficient and fail-safe. > > > > > > [1] as a separate matter, it'd be nice to have a batch version of close(2). > > > > Since /proc is full of gunk, > > People keep saying /proc is bad, but I haven't seen any serious > proposals for a clean replacement. :-) > > > how about adding more to it and making > > the magic symlink of /proc/self/fd for the pidfd to lead to the dirfd > > of the /proc entry of the process it maps to, when one uses > > O_DIRECTORY while opening it? Otherwise, it behaves as it does today. > > It would be equivalent to opening the proc entry with usual access > > restrictions (and hidepid made to work) but without the races, and > > because for processes outside your and children pid ns, it shouldn't > > work anyway, and since they wouldn't have their entry on this procfs > > instance, it would all just fit in nicely? > > Thanks. That'll work. It's a bit magical, but /proc/self/fd is magical > anyway, so that's okay. Please don't do that. /proc/$pid/fd refers to the set of file descriptors the process has open, and semantically doesn't have much to do with the identity of the process. If you want to have a procfs directory entry for getting a pidfd, please add a new entry. (Although I don't see the point in adding a new procfs entry for this when you could instead have an ioctl or syscall operating on the procfs directory fd.)
WARNING: multiple messages have this Message-ID (diff)
From: Jann Horn <jannh@google.com> To: Daniel Colascione <dancol@google.com> Cc: Jonathan Kowalski <bl0pbl33p@gmail.com>, Joel Fernandes <joel@joelfernandes.org>, Christian Brauner <christian@brauner.io>, Konstantin Khlebnikov <khlebnikov@yandex-team.ru>, Andy Lutomirski <luto@kernel.org>, David Howells <dhowells@redhat.com>, "Serge E. Hallyn" <serge@hallyn.com>, "Eric W. Biederman" <ebiederm@xmission.com>, Linux API <linux-api@vger.kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, Kees Cook <keescook@chromium.org>, Alexey Dobriyan <adobriyan@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Michael Kerrisk-manpages <mtk.manpages@gmail.com>, "Dmitry V. Levin" <ldv@altlinux.org>, Andrew Morton <akpm@linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Nagarathnam Muthusamy <nagarat> Subject: Re: [PATCH 0/4] pid: add pidctl() Date: Mon, 25 Mar 2019 21:34:00 +0100 [thread overview] Message-ID: <CAG48ez1ZVKgwfQDYT1k4pB4-8Y8Ywv12dabh5KFFxtKmT-e7Cw@mail.gmail.com> (raw) In-Reply-To: <CAKOZueuYMKdkt8BoSj1+p7=mpe2PA8r7xT5QiF6q3cTK+6HsAA@mail.gmail.com> On Mon, Mar 25, 2019 at 9:15 PM Daniel Colascione <dancol@google.com> wrote: > On Mon, Mar 25, 2019 at 12:42 PM Jonathan Kowalski <bl0pbl33p@gmail.com> wrote: > > On Mon, Mar 25, 2019 at 6:57 PM Daniel Colascione <dancol@google.com> wrote: [...] > > Yes, but everything in /proc is not equivalent to an attribute, or an > > option, and depending on its configuration, you may not want to allow > > processes to even be able to see /proc for any PIDs other than those > > running as their own user (hidepid). This means, even if this new > > system call is added, to respect hidepid, it must, depending on if > > /proc is mounted (and what hidepid is set to, and what gid= is set > > to), return EPERM, because then there is a discrepancy between how the > > two entrypoints to acquire a process handle do access control. > > That's why I proposed that this translation mechanism accept a procfs > root directory --- so you'd specify *which* procfs you want and let > the kernel apply whatever hidepid access restrictions it wants. [...] > > > and 2) it's > > > "fail unsafe": IMHO, most users in practice will skip the line marked > > > "LIVENESS CHECK", and as a result, their code will appear to work but > > > contain subtle race conditions. An explicit interface to translate > > > from a (PIDFD, PROCFS_ROOT) tuple to a /proc/pid directory file > > > descriptor would be both more efficient and fail-safe. > > > > > > [1] as a separate matter, it'd be nice to have a batch version of close(2). > > > > Since /proc is full of gunk, > > People keep saying /proc is bad, but I haven't seen any serious > proposals for a clean replacement. :-) > > > how about adding more to it and making > > the magic symlink of /proc/self/fd for the pidfd to lead to the dirfd > > of the /proc entry of the process it maps to, when one uses > > O_DIRECTORY while opening it? Otherwise, it behaves as it does today. > > It would be equivalent to opening the proc entry with usual access > > restrictions (and hidepid made to work) but without the races, and > > because for processes outside your and children pid ns, it shouldn't > > work anyway, and since they wouldn't have their entry on this procfs > > instance, it would all just fit in nicely? > > Thanks. That'll work. It's a bit magical, but /proc/self/fd is magical > anyway, so that's okay. Please don't do that. /proc/$pid/fd refers to the set of file descriptors the process has open, and semantically doesn't have much to do with the identity of the process. If you want to have a procfs directory entry for getting a pidfd, please add a new entry. (Although I don't see the point in adding a new procfs entry for this when you could instead have an ioctl or syscall operating on the procfs directory fd.)
next prev parent reply other threads:[~2019-03-25 20:34 UTC|newest] Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-25 16:20 [PATCH 0/4] pid: add pidctl() Christian Brauner 2019-03-25 16:20 ` [PATCH 1/4] Make anon_inodes unconditional Christian Brauner 2019-03-25 16:20 ` [PATCH 2/4] pid: add pidctl() Christian Brauner 2019-03-25 17:20 ` Mika Penttilä 2019-03-25 19:59 ` Christian Brauner 2019-03-25 19:59 ` Christian Brauner 2019-03-25 18:18 ` Jann Horn 2019-03-25 18:18 ` Jann Horn 2019-03-25 19:58 ` Christian Brauner 2019-03-25 19:58 ` Christian Brauner 2019-03-26 16:07 ` Joel Fernandes 2019-03-26 16:07 ` Joel Fernandes 2019-03-26 16:15 ` Christian Brauner 2019-03-26 16:15 ` Christian Brauner 2019-03-25 16:20 ` [PATCH 3/4] signal: support pidctl() with pidfd_send_signal() Christian Brauner 2019-03-25 18:28 ` Jonathan Kowalski 2019-03-25 18:28 ` Jonathan Kowalski 2019-03-25 20:05 ` Christian Brauner 2019-03-25 20:05 ` Christian Brauner 2019-03-25 18:39 ` Jann Horn 2019-03-25 18:39 ` Jann Horn 2019-03-25 19:41 ` Christian Brauner 2019-03-25 19:41 ` Christian Brauner 2019-03-25 16:20 ` [PATCH 4/4] tests: add pidctl() tests Christian Brauner 2019-03-25 16:48 ` [PATCH 0/4] pid: add pidctl() Daniel Colascione 2019-03-25 16:48 ` Daniel Colascione 2019-03-25 17:05 ` Konstantin Khlebnikov 2019-03-25 17:07 ` Daniel Colascione 2019-03-25 17:07 ` Daniel Colascione 2019-03-25 17:36 ` Joel Fernandes 2019-03-25 17:36 ` Joel Fernandes 2019-03-25 17:53 ` Daniel Colascione 2019-03-25 17:53 ` Daniel Colascione 2019-03-25 18:19 ` Jonathan Kowalski 2019-03-25 18:19 ` Jonathan Kowalski 2019-03-25 18:57 ` Daniel Colascione 2019-03-25 18:57 ` Daniel Colascione 2019-03-25 19:42 ` Jonathan Kowalski 2019-03-25 19:42 ` Jonathan Kowalski 2019-03-25 20:14 ` Daniel Colascione 2019-03-25 20:14 ` Daniel Colascione 2019-03-25 20:34 ` Jann Horn [this message] 2019-03-25 20:34 ` Jann Horn 2019-03-25 20:40 ` Jonathan Kowalski 2019-03-25 20:40 ` Jonathan Kowalski 2019-03-25 21:14 ` Jonathan Kowalski 2019-03-25 21:14 ` Jonathan Kowalski 2019-03-25 21:15 ` Jann Horn 2019-03-25 21:15 ` Jann Horn 2019-03-25 20:40 ` Christian Brauner 2019-03-25 20:40 ` Christian Brauner 2019-03-25 20:15 ` Christian Brauner 2019-03-25 20:15 ` Christian Brauner 2019-03-25 21:11 ` Joel Fernandes 2019-03-25 21:11 ` Joel Fernandes 2019-03-25 21:17 ` Daniel Colascione 2019-03-25 21:17 ` Daniel Colascione 2019-03-25 21:19 ` Jann Horn 2019-03-25 21:19 ` Jann Horn 2019-03-25 21:43 ` Joel Fernandes 2019-03-25 21:43 ` Joel Fernandes 2019-03-25 21:54 ` Jonathan Kowalski 2019-03-25 21:54 ` Jonathan Kowalski 2019-03-25 22:07 ` Daniel Colascione 2019-03-25 22:07 ` Daniel Colascione 2019-03-25 22:37 ` Jonathan Kowalski 2019-03-25 22:37 ` Jonathan Kowalski 2019-03-25 23:14 ` Daniel Colascione 2019-03-25 23:14 ` Daniel Colascione 2019-03-26 3:03 ` Joel Fernandes 2019-03-26 3:03 ` Joel Fernandes 2019-03-25 16:56 ` David Howells 2019-03-25 16:56 ` David Howells 2019-03-25 16:58 ` Daniel Colascione 2019-03-25 16:58 ` Daniel Colascione 2019-03-25 23:39 ` Andy Lutomirski 2019-03-25 23:39 ` Andy Lutomirski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAG48ez1ZVKgwfQDYT1k4pB4-8Y8Ywv12dabh5KFFxtKmT-e7Cw@mail.gmail.com \ --to=jannh@google.com \ --cc=adobriyan@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=bl0pbl33p@gmail.com \ --cc=christian@brauner.io \ --cc=cyphar@cyphar.com \ --cc=dancol@google.com \ --cc=dhowells@redhat.com \ --cc=ebiederm@xmission.com \ --cc=joel@joelfernandes.org \ --cc=keescook@chromium.org \ --cc=khlebnikov@yandex-team.ru \ --cc=ldv@altlinux.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mtk.manpages@gmail.com \ --cc=nagarathnam.muthusamy@oracle.com \ --cc=oleg@redhat.com \ --cc=serge@hallyn.com \ --cc=tglx@linutronix.de \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.