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

On Wed, Mar 19, 2025 at 06:56:49PM +0300, Gleb Popov wrote:
> On Tue, Mar 11, 2025 at 6:08 PM Konstantin Belousov <kostikbel@gmail.com> wrote:
> >
> > We can provide the FreeBSD procdesc from unix socket for the peer.
> > But you need to evaluate is the result actually useful, taking into
> > account the different semantic.
> 
> I closely studied the pidfd usage across dbus and xdg-desktop-portal,
> here's a breakdown:
> 
> At the lower level dbus just uses SO_PEERPIDFD in only one place to
> obtain a client's pidfd:
> https://gitlab.freedesktop.org/dbus/dbus/-/blob/cddd0a7c94d985587bc0da642841726adf7842ad/dbus/dbus-sysdeps-unix.c#L2343
> 
> It also calls pidfd_open(getpid()) in the other place, but the pidfd
> obtained this way doesn't seem to be used anywhere, so we most likely
> won't need to support this.
> 
> Then at the upper level xdg-desktop-portal obtains the pidfd via dbus
> API and dup()es it:
> 
> https://github.com/flatpak/xdg-desktop-portal/blob/119aad03548f85ed249b7f21cd551f77bc74e4dd/src/xdp-app-info.c#L856
> 
> It then may perform following operations on the pidfd:
> - map pidfd to PID
> https://github.com/flatpak/xdg-desktop-portal/blob/119aad03548f85ed249b7f21cd551f77bc74e4dd/src/xdp-utils.c#L775
> It parses /proc/self/fdinfo/XXXX to get this data, and we can probably
> go with pdgetpid() here.
> - map pidfd to a Linux namespace by reading /proc/XXXX/ns/pid:
> https://github.com/flatpak/xdg-desktop-portal/blob/119aad03548f85ed249b7f21cd551f77bc74e4dd/src/xdp-utils.c#L911
> We can approximate this operation by mapping to JID. The namespace is
> then used to map namespaced pids, but this is irrelevant for us, I
> suppose.
> - close()
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.

> 
> > Also, the waitpid(2) issue might become more serious.
> 
> Yes, this is what confused me the first time I heard about procdesc.
> How come that creating a procdesc fd makes waiting on a PID with
> waitpid(2) impossible?
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.