Race-free process creation in the GNU C Library

Posted Sep 7, 2023 9:06 UTC (Thu) by Jonno (subscriber, #49613)
In reply to: Race-free process creation in the GNU C Library by cyphar
Parent article: Race-free process creation in the GNU C Library

> I have wondered whether it would be possible to allow fsopen("proc") to unprivileged processes but only for subset=pids

That would still let the unprivileged process learn of other processes on the system that it otherwise would be oblivious about.

But perhaps allowing something like `openat(pidfd, ".", O_DIRECTORY)` to get a fd equivalent to the /proc/<pid> directory except you can't ".." out of it would work.

Race-free process creation in the GNU C Library

Posted Sep 9, 2023 5:03 UTC (Sat) by cyphar (subscriber, #110703) [Link] (1 responses)

v1 pidfds kind of worked this way, my understanding is that there were a bunch of issues with creating handles to procfs mounts and thus only a few pidfd operations work with that style -- the new ones are all anonymous inodes (like most other fd interfaces).

It's a bit of a shame, because that could've been the nicest behaviour -- though the contents of quite a few procfs files depend on the pid namespace associated with the procfs in ways that will cause confusion when sending them between processes and I'm not sure there would be a nice solution for that.

Race-free process creation in the GNU C Library

Posted Sep 16, 2023 14:35 UTC (Sat) by Jonno (subscriber, #49613) [Link]

> v1 pidfds kind of worked this way
Not quite. The first version of fd references to a pid was by open("/proc/«pid»", O_DIRECTORY) [or open("/proc/self", O_DIRECTORY)], giving you a directory fd that was guaranteed to never refer to an newer process, even if the pid was reused (it would instead refer to an unlinked directory). The problem was that this (1) required a mounted procfs to work, and (2), could not be used for polling or waitid. The upshot was that, being a directory fd, you could use it to open files in the procfs directory of the process in question.

To re-gain that ability without the old problems you need some race-free way of going from a pidfd to the corresponding dirfd without a mounted procfs. Simply getting a procfs reference for use in *at syscalls without actually mounting procfs (as proposed by Karellen) would make it possible for live processes, but not for exited processes still referred to by a pidfd, and it wouldn't be race-free. My proposal using openat, or some new flag to dup3 or fcntl, would solve it fully.