Re: [PATCH v8 0/7] Add pidfd and cgroupv2 support for process creation

[Rich Felker <dalias@libc.org>]

On Fri, Aug 18, 2023 at 11:06:35AM -0300, Adhemerval Zanella via Libc-alpha wrote:
> The glibc 2.36 added wrappers for Linux syscall pidfd_open, pidfd_getfd,
> and pidfd_send_signal, and exported the P_PIDFD to use along with
> waitid. The pidfd is a race-free interface, however, the pidfd_open is
> subject to TOCTOU if the file descriptor is not obtained directly from
> the clone or clone3 syscall (there is still a small window between the
> clone return and the pidfd_getfd where the process can be reaped and the
> process ID reused).

Unless I'm missing something, that window is purely programmer error.
The pid belongs to the parent process, that called fork, posix_spawn,
clone, or whatever, and is responsible for not freeing it until it's
done using it.

Yes this can happen if you install a SIGCHLD handler that reaps
anything it sees, or if you're calling wait without a pid. This is
programming error. If you're stuck with code outside your control that
makes that mistake, you can already avoid it with clone by setting the
child exit signal to 0 rather than SIGCHLD. But it's best just not to
do that.

IMO making a new, complex, highly nonstandard interface to work around
a problem that's programmer error, and getting this nonstandard and
nonportable pattern into mainstream software, has negative value.

Rich