Re: Would we want pidfd_open(2) & SO_PEERPIDFD?

On Tue, Mar 25, 2025 at 09:49:26AM +0000, David Chisnall wrote:
> On 25 Mar 2025, at 05:27, Gleb Popov <arrowd@freebsd.org> wrote:
> > 
> > On Tue, Mar 25, 2025 at 8:04 AM Konstantin Belousov <kostikbel@gmail.com> wrote:
> >> 
> >> Can this be summarized as just a use of pidfd to
> >> - get the pid of the peer
> >> - ensure the peer liveness?
> >> 
> >> I do not see much need of pidfd for this functionality.
> > 
> > What's the alternative? Tapping into a socket with
> > getsockopt(LOCAL_PEERCRED) to obtain a PID via xucred is not an option
> > because a client is not required to maintain an established connection
> > to a D-Bus socket.
> > 
> > The high level code expects a descriptor with some properties, so we
> > either provide it or have to patch large parts of the code using it.
> > Emulating pidfd somehow is also fine to me, but I have no idea how to
> > do that. libinotify-kqueue example shows that emulating a descriptor
> > with certain properties is quite a non-trivial task.
> 
> It’s worth noting that DBUS is not the only thing that wants a race-free way of naming a process.  Debuggers also have this problem.  On XNU, the debugger uses the Mach task port, which is not completely like a process descriptor.  When the target process exits, the task port will report errors.  This eliminates the races that are intrinsic to the ptrace APIs.  Extending process descriptors to subsume ptrace behaviour (and adding thread descriptors that avoid the same races on threads) and avoid these races has been on my wishlist for a long time.  Doing this would require some Capsicum permissions on process descriptors (not every holder of a process descriptor should be able to ptrace it).  
> 
There is no races with ptrace(2).  Attached debuggee pid is not worse than a
handle, it cannot go away.

> It would probably be good to collect the desired behaviours for process descriptors and do a proper implementation of the desired feature set.  Currently, process descriptors serve precisely one need: Capsicum processes can use them to wait for process termination without needing access to the global PID namespace.
> 
> David
>