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

[Luca Boccassi <bluca@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]

> On 18/08/23 14:51, Rich Felker wrote:
> > 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.
> > 
> 
> Yes, this is the issue GNOME is having with their code base [1] and
> that
> motivated this new interface.  Systemd also seems to be interested in
> these interface, although I am not sure if it is also subject to same
> issue.
> 
> I don't have a strong opinion whether this should be considered a
> solid
> reason to provide a new API, another option would to close BZ#30349
> [2] 
> as wontfix with this rationale.  However, this does not really
> provide 
> an workaround, and worse it will pass the idea that to fully resolve
> it 
> you will need either to allow the racy condition or issue clone
> directly.

These are real race conditions, that cannot be solved otherwise,
characterizing them as 'programming errors' is very misleading and
wrong.

We very much need both of those interfaces in systemd, and fully intend
to use them as soon as they are available. We are slowly moving towards
using pidfds everywhere to be able to do end-to-end race-free process
tracking and management, and these are fundamental pieces for this
effort. From what I can read the GNOME developers feel the same way,
and I wouldn't be surprised if QT followed suit too given what you
mentioned in the cover letter.

Surely implementing useful, core functionality for the direct and
immediate benefit of 3 major Linux projects is a reason as solid as you
could ever find to add a new interface.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]