Date: Tue, 11 Mar 2025 17:08:39 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Gleb Popov <arrowd@freebsd.org> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Would we want pidfd_open(2) & SO_PEERPIDFD? Message-ID: <Z9BR90ijwniJr2IJ@kib.kiev.ua> In-Reply-To: <CALH631m7DZKOLkjn4Z9z7arE9xwfEEjaGVSO=5KyHJ=iZ8o9Qw@mail.gmail.com> References: <CALH631mgztNmngL1Hffbbcf0n-kLZP-2YmsMLJ8Xi33HV8uuvw@mail.gmail.com> <Z6udhDuj4uBjNUsM@kib.kiev.ua> <CALH631=7MnCAe67yPqG%2BAJfy_CPxf3HUxsfeVvgmiTEXEy27Bg@mail.gmail.com> <Z6wuyS4uBQJbCG-c@kib.kiev.ua> <CALH631m7DZKOLkjn4Z9z7arE9xwfEEjaGVSO=5KyHJ=iZ8o9Qw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 11, 2025 at 10:12:33AM +0300, Gleb Popov wrote: > 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/ 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. Also, the waitpid(2) issue might become more serious.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Z9BR90ijwniJr2IJ>