From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH v2 0/5] pid: add pidfd_open() Date: Mon, 1 Apr 2019 15:13:23 -0700 Message-ID: References: <132107F4-F56B-4D6E-9E00-A6F7C092E6BD@amacapital.net> <20190331211041.vht7dnqg4e4bilr2@brauner.io> <18C7FCB9-2CBA-4237-94BB-9C4395A2106B@amacapital.net> <20190401114059.7gdsvcqyoz2o5bbz@yavin> <20190401194214.4rbvmwogpke3cjcx@brauner.io> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Jonathan Kowalski Cc: Christian Brauner , Jann Horn , Daniel Colascione , Aleksa Sarai , Andy Lutomirski , 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 , "Dmitry V. Levin" , Andrew Morton List-Id: linux-api@vger.kernel.org On Mon, Apr 1, 2019 at 2:58 PM Jonathan Kowalski wrote: > > You mention the race about learning the PID, PID being recycled, and > pidfd_open getting the wrong reference. > > This exists with the /proc model to way. How do you propose to address this? Note that that race exists _regardless_ of any interfaces. pidfd_open() has the same race: any time you have a pid, the lifetime of it is only as long as the process existing. That's why we talked about the CLONE_PIDFD flag, which would return the pidfd itself when creating a new process. That's one truly race-free way to handle it. Or just do the fork(), and know that the pid won't be re-used until you've done the wait() for it, and block SIGCHLD until you've done the lookup. That said, in *practice*, you can probably use any of the racy "look up pidfd using pid" models, as long as you just verify the end result after you've opened it. That verification could be as simple as "look up the parent pid of the pidfd I got", if you know you created it with fork() (and you can obviously track what _other_ thread you yourself created, so you can verify whether it is yours or not). For example, using "openat(pidfd, "status", ..)", but also by just tracking what you've done waitpid() on (but you need to look out for subtle races with another thread being in the process of doing so). Or you can just say that as long as you got the pidfd quickly after the fork(), any pid wrapping attack is practically not possible even if it might be racy in theory. Linus