@2ffa8eb4 partially related, is there any hope that the in kernel IPC mechanism that was attempted with kdbys/bus-1 will make a resurgence? 

Somehow relying on D-BUS doesn't feel like a great security improvement over suid. 

 @b722fd86 unlikely. And D-Bus has its weaknesses, but security-wise it's a lot more sound than suid/fcaps mess. It has interactive auth via Polkit even. I mean, I'd do it differently sure in my ideal world that only exists in my head, but it's a fundamental improvement over fucking suid/fcaps, hence all power to D-Bus. 

 @2ffa8eb4

sudo(){
    ssh "$1"@928da66a
} 

 @0988e86d as a first step towards that goal distros should start binding ssh to some well--known fixed AF_UNIX socket, so that people can just use it on the local host, and between local containers. 

 @2ffa8eb4 hm. But that basically necessitates solid RPC between an unprivileged client and a privileged system management daemon, which in itself is exactly where we tend to find parsing bugs for decades (like the glibc one triggering this discussion is).
I'd honestly rather see a kind-of-single-syscall-suid mechanism that only works with a sensible verifiable pledge()-equivalent. Like, think of an xattr that contains ebpf code describing that a privileged open can open exactly one file, and... 

 @5ef65a7f sorry, but IPC based elevation, where privileged processes are clearly separated and reasonably isolated is always better than a mess where a process gains privileges and continues running.

I am sure privileges should never be gained, they should only be dropped. 

 @2ffa8eb4 @5ef65a7f yeah, we don't need more magic privilege escalation in the kernel. 

 @2ffa8eb4 paired with the ability to turn off set*id completely through a Kconfig option. 

 @2ffa8eb4 Ah yes, Lennart (m$ employee) tries to fix security forever by replacing simple suid binaries with much more complicated IPC privilege elevation.