Race-free process creation in the GNU C Library

Posted Sep 2, 2023 7:02 UTC (Sat) by ibukanov (subscriber, #3942)
Parent article: Race-free process creation in the GNU C Library

Hm, I thought that pid could only be reused after the parent process called waitpid. So obtaining pidfd should always be OK as long as one does that before waitpid. If this is not the case, that seems like a bad bug in Linux.

Race-free process creation in the GNU C Library

Posted Sep 2, 2023 10:14 UTC (Sat) by bluca (subscriber, #118303) [Link] (2 responses)

Reliably identifying a process is not something that only its parent does. pidfds can be passed over to other arbitrary processes via SCM_PIDFD/SO_PEERPIDFD.

Race-free process creation in the GNU C Library

Posted Sep 2, 2023 10:57 UTC (Sat) by darmengod (subscriber, #130659) [Link] (1 responses)

So with existing interfaces the parent can know a child's PID and (race-free) get a pidfd to it, as long the precautions in pidfd_open(2) - NOTES are observed.

But when it sends the pidfd to some other process, the receiver has no way to get the PID (number) without /proc being accessible, and that is undesirable.

Couldn't this be resolved by convention at the application layer? So the original parent process doesn't just send an empty message with SCM_PIDFD attached, but includes the PID as a number in the regular message payload?

Race-free process creation in the GNU C Library

Posted Sep 2, 2023 11:09 UTC (Sat) by bluca (subscriber, #118303) [Link]

That doesn't allow the receiver to verify anything, it's not just about knowing the pid, it's about knowing that it is still owned by the original process and not a recycled one. This is a real-world problem that has caused several CVEs, for example in polkit, and that so far has only been partially worked around by using unreliable heuristic like the start time in the target's proc/pid/status and other metadata, that can make it harder to exploit but not impossible