Going straight to D-Bus feels excessive. Here's an 85-line file I had lying around that should cover most cases of FD passing: https://paste.rs/6FBFS.c.

There are a few existing libraries like libancillary that would do this for you and provide some level of OS compatibility.

Libancillary achieves more or less the same thing with more or less the same amount of code. I do still need to test compatibility with non-Linux Unices beyond checking the manuals. (If only I had jart’s stable of premade VMs for this purpose so it wasn’t such a pain.)

APIs are/were designed for completeness more than friendliness. Speaking of sendmsg, the whole BSD socket API is plain horrible; it only takes a couple of uses to realize that you never want to use it directly again; you either make your own library on top of it, or a class, or whatever form of code reuse the language deems appropriate.

> the whole BSD socket API is plain horrible; it only takes a couple of uses to realize that you never want to use it directly again

That was my initial impression as well, but recently I’ve had to use it again and surprisingly did not find as bad as I remembered. Except, indeed, for the fd-passing experience, for which see my wrapper elsewhere in the thread (also other sideband stuff, but how often do you really need SCM_CREDENTIALS?).

The syscall/kernel-ABI people seem to love it as well—I remember reading an article that praised it for remaining so stable over its lifetime. I think these are actually two sides of the same coin: BSD sockets essentially layer a second ABI on top of C function invocations. It’s a tad more specific than generic ioctl-ish (selector, payload), but not that much, and the farther away you are from the happy path of send()/recv(), the closer it is to that (and the more extension capability the kernel programmer wants, and the more misery the userland programmer feels).

The Unix approach of exposing syscalls from libc essentially directly was a nice thought, but the sockets API feels like a reductio ad absurdum of it.

SCM_CREDENTIALS may be useful for some programs on UNIX systems, but for a better designed capability-based system, SCM_CREDENTIALS is a bad idea.

SCM_RIGHTS is useful though.

I also think that there are several problems with the design and implementation of D-bus.

Only because it wraps sendmsg in a nicer API at the language level - something you could also do with raw sendmsg.