> The don't solve race conditions in peers trying to locate each other (surprisingly difficult).
There's only one PID 1 - it would not be hard to locate its UNIX domain socket.
> They don't solve a standardized marshaling format.
Fair point.
> They don't come with an implementation to integrate with main loops for event polling.
They're file descriptors so they work with select, poll, etc.
> They have an inherent vulnerability in FD passing where you can cause the peer to lock up.
Please elaborate. There's nothing inherently vulnerable with FD passing. In fact, dbus relies on it so if you can't make FD passing secure then you can't make dbus secure either.
> You can get into deadlock situations in your messaging code if you aren't really careful about message sizes and when you order poll in/poll out.
I think you're overstating the difficulty of doing this correctly.
> They aren't introspect-able to see what the peer supports.
I for one am OK with PID 1 not being introspectable.
> They make it super easy to not maintain ABI.
It's quite possible to maintain ABI compatibility, but still, how much of a moving target should PID 1's ABI be anyways?
dbus is a great solution for normal applications, but PID 1 is special. The generality provided by dbus is unnecessary. PID 1 should not be servicing requests from ordinary users, so any security concerns with using UNIX domain sockets directly are moot. If there are certain actions, such as shutdown, that need to be triggered from non-root users, then there should be a separate, unprivileged, process that listens on dbus, implements authorization logic, and then relays the command to PID 1 over a UNIX domain socket using a very simple and easily-audited interface. That's good security and reliability engineering.
There's only one PID 1 - it would not be hard to locate its UNIX domain socket.
> They don't solve a standardized marshaling format.
Fair point.
> They don't come with an implementation to integrate with main loops for event polling.
They're file descriptors so they work with select, poll, etc.
> They have an inherent vulnerability in FD passing where you can cause the peer to lock up.
Please elaborate. There's nothing inherently vulnerable with FD passing. In fact, dbus relies on it so if you can't make FD passing secure then you can't make dbus secure either.
> You can get into deadlock situations in your messaging code if you aren't really careful about message sizes and when you order poll in/poll out.
I think you're overstating the difficulty of doing this correctly.
> They aren't introspect-able to see what the peer supports.
I for one am OK with PID 1 not being introspectable.
> They make it super easy to not maintain ABI.
It's quite possible to maintain ABI compatibility, but still, how much of a moving target should PID 1's ABI be anyways?
dbus is a great solution for normal applications, but PID 1 is special. The generality provided by dbus is unnecessary. PID 1 should not be servicing requests from ordinary users, so any security concerns with using UNIX domain sockets directly are moot. If there are certain actions, such as shutdown, that need to be triggered from non-root users, then there should be a separate, unprivileged, process that listens on dbus, implements authorization logic, and then relays the command to PID 1 over a UNIX domain socket using a very simple and easily-audited interface. That's good security and reliability engineering.