A new filesystem for pidfds (2024)
14 points by runxiyu
14 points by runxiyu
Oh, I know this one! It's a copy of FreeBSD's process descriptors, which are inspired by Mach task handles.
Indeed! I spent some time scouring xnu source to find a way to atomically get a task handle from a spawned process to avoid PID races and came up short. I thought about adding a new posix_spawn action to return it to the parent process but gave up because it's not like a custom XNU kernel is very useful.
Chortle:
one of the advantages of the new filesystem is that it exposed pidfd operations to security modules, which is something that the policy maintainers had requested. The downside is that it exposed those operations to security modules, one of which promptly set about denying them.
For quite a while I thought that holding on to the pidfd makes the underlying PID not recycle. I appear to be wrong, and it does appear that /proc/pidfd_getpid(pidfd) is racy.
Same here. Alas. But since the pidfd is guaranteed to keep referring to the original process, you can use the PID (that you got from the pidfd) to acquire whatever PID-based info you want, and then go back to the pidfd and see if the PID you used is still associated with it after you are done. If not, you have to discard anything you obtained by means of the PID. That should avoid any race.
What's a bit yuck, however, is that getting a PID from a pidfd still involves parsing a file in procfs :-(