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

On 3/25/25 04:49, David Chisnall wrote:
> On 25 Mar 2025, at 05:27, Gleb Popov <arrowd@freebsd.org> wrote:
>>
>> On Tue, Mar 25, 2025 at 8:04 AM Konstantin Belousov <kostikbel@gmail.com> wrote:
>>>
>>> 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.
>>
>> What's the alternative? Tapping into a socket with
>> getsockopt(LOCAL_PEERCRED) to obtain a PID via xucred is not an option
>> because a client is not required to maintain an established connection
>> to a D-Bus socket.
>>
>> The high level code expects a descriptor with some properties, so we
>> either provide it or have to patch large parts of the code using it.
>> Emulating pidfd somehow is also fine to me, but I have no idea how to
>> do that. libinotify-kqueue example shows that emulating a descriptor
>> with certain properties is quite a non-trivial task.
> 
> It’s worth noting that DBUS is not the only thing that wants a race-free way of naming a process.  Debuggers also have this problem.  On XNU, the debugger uses the Mach task port, which is not completely like a process descriptor.  When the target process exits, the task port will report errors.  This eliminates the races that are intrinsic to the ptrace APIs.  Extending process descriptors to subsume ptrace behaviour (and adding thread descriptors that avoid the same races on threads) and avoid these races has been on my wishlist for a long time.  Doing this would require some Capsicum permissions on process descriptors (not every holder of a process descriptor should be able to ptrace it).
> 

FWIW, I've tossed around similar ideas with csjp@ while thinking about 
lsan in a capsicumized world.  For lsan, we need to fork then ptrace the 
parent to pause all threads and then capture the current state to analyze.

It'd be useful to be able to generate a procdesc (or something similar) 
for the 'current process' and implement a ptracepfd(2) that can use it 
if the nonexistent CAP_PTRACE rights(4) hasn't been stripped.  We'd then 
use it as a way for the parent to be able to grant a sandboxed child the 
authority to ptrace it in a way that doesn't violate the spirit of capsicum.

> It would probably be good to collect the desired behaviours for process descriptors and do a proper implementation of the desired feature set.  Currently, process descriptors serve precisely one need: Capsicum processes can use them to wait for process termination without needing access to the global PID namespace.
> 
> David
> 
>