Date: Tue, 11 Feb 2025 20:57:08 +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: <Z6udhDuj4uBjNUsM@kib.kiev.ua> In-Reply-To: <CALH631mgztNmngL1Hffbbcf0n-kLZP-2YmsMLJ8Xi33HV8uuvw@mail.gmail.com> References: <CALH631mgztNmngL1Hffbbcf0n-kLZP-2YmsMLJ8Xi33HV8uuvw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 11, 2025 at 09:03:20PM +0300, Gleb Popov wrote: > Hey hackers. > > D-Bus services can obtain PIDs of their clients via the sendmsg(2) > mechanism over unix sockets (or getsockopt(SO_PEERCRED)). But > operating on PIDs is racy, so to make sure the process has not been > terminated a service would need to call getsockopt(SO_PEERCRED) again. > It isn't immediately possible with D-Bus API and would require hacking > on its code. > > However, Linux has a better alternative for this case - > getsockopt(SO_PEERPIDFD) [1]. The call returns a pidfd (see > procdesc(4)), which is pinned to the caller process. DBus already > supports this [2], so if FreeBSD implements SO_PEERPIDFD the feature > will work for us out of the box. > > My question is - would it be possible for FreeBSD to support > SO_PEERPIDFD or I'd be better off to hack on D-Bus internals? > > Thanks in advance. > > [1] https://blog.sebastianwick.net/posts/so-peerpidfd-usefulness/ > [2] https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/398#b9391b9a8a6c8fb67b48b03b25e8893befbeff87 The semantic of the Linux' fd returned by pidfd_open() is not compatible with our pidfd. And it cannot be fixed/changed.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Z6udhDuj4uBjNUsM>