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

[Christian Brauner <brauner@kernel.org>]

On 2026-09-09 23:33 -0700, Kuniyuki Iwashima wrote:
> On Wed, Sep 9, 2026 at 3:43 AM Christian Brauner <brauner@kernel.org> wrote:
> >
> > 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!