(1) Are developers aware that Bluetooth sockets even support SO_PEERPIDFD?
(2) Is this useful for Bluetooth user space implementations?/Is this already used?
(3) Is it useful to also enable SO_PEERPIDFD for reaped peers for Bluetooth sockets?

The fun part is that Alex reminded me that Bluetooth sockets support at least SO_PEERPIDFD. I had forgotten about this and had blocked adding SCM_PIDFD support for them.

They don't yet support reaped SO_PEERPIDFD but they could be made to do so. I wonder mainly three things:

So all we really needed to do is register the peer in pidfs (the FS pidfds are based on for a while now). By doing this we're guaranteed that when the peer task gets reaped exit information will be available and we can safely allocate pidfds later on.

The advantage of the peer credential concept is of course that we stash the required reference (struct pid) at the time when the peer is still alive.

So we already have a stable in-kernel handle.

Ever since v6.15 it's possible to retrieve the exit status and cgroup ID from the pidfd via the PIDFD_INFO_EXIT flag of the PIDFD_GET_INFO ioctl() after the process has been reaped.

So with this it becomes even more useful to hand out pidfds for already reaped peer processes.

It's used by dbus-broker, polkit and systemd to guard against pid recycling and related issues.

So far it wasn't possible to get a pidfd if the peer process was already reaped. But there wasn't anything technically wrong with enabling this.

Any process that doesn't have that {g,u}id but is still privileged otherwise will write to disk as the squashed {g,u}id. I just finished a draft and selftests that miraculously work.