Date: Tue, 25 Mar 2025 07:04:23 +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: <Z-I5Vwb3383R6UZs@kib.kiev.ua> In-Reply-To: <CALH631mhpv7tzr1vhNgF2Hs6=ynSrMeuP1=NeXU63FEAmfUwRw@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> <Z9BR90ijwniJr2IJ@kib.kiev.ua> <CALH631mhpv7tzr1vhNgF2Hs6=ynSrMeuP1=NeXU63FEAmfUwRw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Z-I5Vwb3383R6UZs>