A quick overview of the work in progress to plumb PID FDs through Linux userspace, to achieve resilience and security improvements
Process ID File Descriptors were introduced in Linux v5.3. They allow tracking a process reliably, without risking races and reuse attacks, as they always refer to one single process regardless of the actual PID, so if the process goes away the file descriptor will become invalid, even if a new process with the same PID reappears at the same time.
Tracking processes in userspace is needed for various purposes, for example to authenticate actions via Polkit. This has been historically fragile, and various workarounds such as tracking a PID plus a UID plus a start time were put in place. D-Bus implementations also have methods to query a D-Bus' endpoint's PID, UID and GIDs.
Recently work has been done to plumb PID FDs through all these components - systemd is able to receive queries asking for the session information or unit information via a PID FD, D-Bus implementations return the PID FD of a D-Bus endpoint via GetConnectionCredentials()/GetConnectionUnixProcessFD() (and they track processes via FD rather than PID), and Polkit allows writing rules authorizing by the systemd service name, which is possible to do safely thanks to using FDs all the way through.
This lightning talk will quickly go through these improvements, showing how PID FDs can be used to improve userspace and provide concrete benefits.