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

On Wed, Feb 12, 2025 at 8:17 AM Konstantin Belousov <kostikbel@gmail.com> wrote:
>
> On Wed, Feb 12, 2025 at 07:10:25AM +0300, Gleb Popov wrote:
> > On Tue, Feb 11, 2025 at 9:57 PM Konstantin Belousov <kostikbel@gmail.com> wrote:
> > >
> > >
> > > The semantic of the Linux' fd returned by pidfd_open() is not compatible
> > > with our pidfd.
> >
> > What's the difference, exactly?
> > I mean, it is still a descriptor and the only thing I need to do with
> > it is check if it is still open. We even have pdgetpid() to go from
> > the fd to a PID. This all looks like a perfect match to me.
>
> Read the man page for Linux pidfd_open(), and compare with our procdesc(4).
> The one feature _you plan to use_ might be almost identical, but everything
> else is different.

When I started this thread the only use case I had was my own D-Bus
service I'm writing. Now it turned out that a new version of
xdg-desktop-portal [1] also started to rely on pidfd's passed by
callers.

I agree that our procdesc is indeed different compared to Linux pidfd,
but not having a compatibility shim of some sort would mean a lot of
non-upstreamable patching for dbus and xdg-desktop-portal. I'm not
skilled enough to determine what parts of this API can be emulated in
a userland library a-la libepoll-shim or libudev-dev. At the bare
minimum I need a way to obtain a procdesc from a connected unix socket
via getsockopt(LOCAL_PEERCRED) or something like that.

[1] https://github.com/flatpak/xdg-desktop-portal/