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

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Tue, 11 Feb 2025 18:57:08 UTC 
On Tue, Feb 11, 2025 at 09:03:20PM +0300, Gleb Popov wrote:
> Hey hackers.
> 
> D-Bus services can obtain PIDs of their clients via the sendmsg(2)
> mechanism over unix sockets (or getsockopt(SO_PEERCRED)). But
> operating on PIDs is racy, so to make sure the process has not been
> terminated a service would need to call getsockopt(SO_PEERCRED) again.
> It isn't immediately possible with D-Bus API and would require hacking
> on its code.
> 
> However, Linux has a better alternative for this case -
> getsockopt(SO_PEERPIDFD) [1]. The call returns a pidfd (see
> procdesc(4)), which is pinned to the caller process. DBus already
> supports this [2], so if FreeBSD implements SO_PEERPIDFD the feature
> will work for us out of the box.
> 
> My question is - would it be possible for FreeBSD to support
> SO_PEERPIDFD or I'd be better off to hack on D-Bus internals?
> 
> Thanks in advance.
> 
> [1] https://blog.sebastianwick.net/posts/so-peerpidfd-usefulness/
> [2] https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/398#b9391b9a8a6c8fb67b48b03b25e8893befbeff87

The semantic of the Linux' fd returned by pidfd_open() is not compatible
with our pidfd.  And it cannot be fixed/changed.