I could go on.
> The don't solve race conditions in peers trying to locate each other (surprisingly difficult).
Not even sure what you mean here. Are you talking about peer discovery? Because DBus won't help you there either--peers have to be aware of each other's DBus object paths before they can rendezvous. Similarly, two peers need to know where the common pipe is to rendezvous.
> They don't solve a standardized marshaling format.
Nor should they. There are a ton of ways to skin this cat in userspace, depending on what your application needs. Protobufs come to mind, for example, but there are others.
Why do you want the pipe to enforce a particular marshaling format? Does the pipe know what's best for every single application that will ever use it?
> They don't come with an implementation to integrate with main loops for event polling.
It's not the kernel's responsibility to implement the application's main loop. That's what libevent and friends are for today, if you need them.
> They have an inherent vulnerability in FD passing where you can cause the peer to lock up.
Last I checked, you pass file descriptors via UNIX sockets, not pipes.
> They don't handle authentication (well, sort of).
Depends on your application's threat model. The kernel provides some basic primitives that can be used to address common security-related problems (capabilities, permission bits, users, groups, and ACLs). If they're not enough, you're free to perform whatever authentication you need in userspace to secure your application against your threat model's adversaries.
It is unreasonable to expect the pipe to be aware of every single threat model an applications expects, especially since they change over time.
> 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.
It's not the pipe's fault if you don't use it correctly.
> They aren't introspect-able to see what the peer supports.
Peer A could use the pipe to ask peer B what it can do for peer A. Why do you want the pipe to do peer B's job?
> They make it super easy to not maintain ABI.
Nor does DBus. Nothing stops an application from willy-nilly changing the data it serves back.
I suspect he was referring to socket activation and how that simplifies these kinds of messes.
> Nor should they. There are a ton of ways to skin this cat in userspace, depending on what your application needs. Protobufs come to mind, for example, but there are others.
Right... so that's exactly what systemd did. It used Dbus, which provides that standard serialization format. Not my favourite format, but very well established and tested and focused on systemd's problem domain.
The point is, in order to have loose coupling between components, something like unix pipes is just a starting point.
> Does the pipe know what's best for every single application that will ever use it?
Ah, now I understand the problem with systemd. I never realized it was trying to take over every application's communications protocol! ; -)
Seriously, I think it is perfectly reasonable (and necessary) to define a standard protocol for system even notifications... I say this because it has already been done... by the standard compoents like udev & dbus that systemd is building on top of...
> Last I checked, you pass file descriptors via UNIX sockets, not pipes.
Correct. People have a tendency to mess up their semantics though. If the original poster wasn't referring to unix domain sockets, than it is an even sillier question.
> It is unreasonable to expect the pipe to be aware of every single threat model an applications expects, especially since they change over time.
Yes, but you do need something more sophisticated than a pipe to manage secure communications between your systems components.
> Nor does DBus. Nothing stops an application from willy-nilly changing the data it serves back.
? D-Bus will drop you like a hot potato the moment you fire off invalid messages. You could send valid messages with fraudlent/misleading data payloads I guess, but at least a whole host of problems are addressed by tightening that up.
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.
(It's kind of unfair but I could not resist): Just like dbus today? http://www.ubuntu.com/usn/usn-2352-1/
