Re: [PATCH v2 00/10] net: support thread-specific pidfds for send and connect

On 2026-09-09 23:33 -0700, Kuniyuki Iwashima wrote:

On Wed, Sep 9, 2026 at 3:43 AM Christian Brauner [off-list ref] wrote:

quoted

SO_PASSPIDFD/SCM_PIDFD and SO_PEERPIDFD allow to retrieve a pidfd for
the thread-group leader. The coredump server using the coredump socket
cannot get a handle on the task that took the signal and is writing the
coredump easily. Workloads interested in per-thread authentification
have similar problems.

Add SO_PASSPIDFD_THREAD and SO_PEERPIDFD_THREAD. We record the sending
and the connecting thread in addition to the thread-group leader.

SO_PASSPIDFD_THREAD functions like SO_PASSPIDFD but instead of an
SCM_PIDFD message for the thread-group leader, SCM_PIDFD sends a pidfd
for the specific thread. SO_PASSPIDFD_THREAD is mutually exclusive with
SO_PASSPIDFD. The last one set takes precedence and disables the other
one. Both SO_PASSCRED and SO_PASSPIDFD receivers see one writer per
process as before.

SO_PEERPIDFD_THREAD allows to retrieve a pidfd for the specific thread
that called connect(), listen(), or socketpair().

pidfs_coredump() now also stamps the dumping thread's struct pid so a
pidfd for that thread reports the coredump like the pidfd of the
thread-group leader does.

systemd-coredump currently uses SO_PEERPIDFD, so

And dbus-broker and polkit and etc pp.

SO_PEERPIDFD_THREAD makes sense to me, but is there
real need/use-case to fetch each thread's pidfd per sendmsg()
via cmsg ?

I want to be able to authenticate individual threads in a thread-group
on a per message basis in an authentication framework.

Thanks for the review!