Re:The Unix process API is unreliable and unsafe
by cryptonector on Friday March 24, 2023 @12:38AM
(#35285146)
> There is no such thing that allows you to avoid the race condition. There are a few issues:
> - You can't control every call to open, and thus enforce O_CLOEXEC on all files (by default)
Eh, you can if you open-code everything that might not call `pipe2(2)`, or `accept4(2)`, etc. It's not great, but it is possible. You can also LD_PRELOAD a shim to make everything do that -- also not great, but possible.
You can also do the spawn server thing, which solves the problem, though you need to spawn the spawn server early, and if not, well, yeah.
You can also close (on the child side of vfork()) all the FDs you don't know. That mostly works, unless you are running in a context where you need to keep some FDs you don't know about.
We don't have a time machine. We only have these workarounds. It's not all bad.
> - You can't control every call to open, and thus enforce O_CLOEXEC on all files (by default)
Eh, you can if you open-code everything that might not call `pipe2(2)`, or `accept4(2)`, etc. It's not great, but it is possible. You can also LD_PRELOAD a shim to make everything do that -- also not great, but possible.
You can also do the spawn server thing, which solves the problem, though you need to spawn the spawn server early, and if not, well, yeah.
You can also close (on the child side of vfork()) all the FDs you don't know. That mostly works, unless you are running in a context where you need to keep some FDs you don't know about.
We don't have a time machine. We only have these workarounds. It's not all bad.