Race-free process creation in the GNU C Library

Posted Sep 2, 2023 2:55 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
In reply to: Race-free process creation in the GNU C Library by alkbyby
Parent article: Race-free process creation in the GNU C Library

> There are definitely libraries doing sub-process spawning. E.g. I recently learned tensorflow does to compile some hw accelerator codes.

Then they are quite likely unsafe, though in practice they would work fine in the vast majority of cases because typical race windows are pretty narrow. You really need malicious input and/or users to exploit that.

Race-free process creation in the GNU C Library

Posted Sep 2, 2023 4:07 UTC (Sat) by alkbyby (subscriber, #61687) [Link]

> Then they are quite likely unsafe, though in practice they would work fine in the vast majority of cases because typical race windows are pretty narrow. You really need malicious input and/or users to exploit that.

Well, your comment above about reparenting is only right for pid 1. And I am not sure how much software there is that "steals" other modules/libraries dead kids. My impression is there shouldn't be much.

I quickly inspected libuv for sub-process spawning, they don't steal. And glib. They also do the right thing (even with pidfd when available, since pidfd can be nicely polled).

With all that I am still curious what might the use-cases that people try to fix by proposed pidfd_spawn API. So far we've established it could be:

a) when process breaks wait{,pid} by ignoring SIGCHLD

b) when process has things that steal dead kids

But perhaps there are more. And I am curious how common those "bad" cases might be.