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

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.

> pidfd takes ownership of the parent/child relation.  Wait() family of the
> functions clean after zombies, but this functionality is subsumed by
> the procdesc, so it is 'kind of' contradicts each other.  Also, as I
> can guess, wait() contradicts the capsicum idea of representing all
> access rights as file descriptors, since the special relation with the
> child presented yet another special process right.

Yes, this is a problem, and I have no experience to have an opinion there.