davmac

late reply, I know - I only just saw this discussion - I didn't post this story to HN myself. However:

I recently wrote a blog post discussion why I created Dasynq, here: https://davmac.wordpress.com/2017/12/17/introducing-dasynq/

Though I don't specifically discuss boost::asio there, I believe some of the points made there apply. Also, last time I checked, boost::asio mandated linking with threads library (at least for some features) whereas Dasynq doesn't, and boost::asio didn't offer support for watching POSIX signals or child process termination (Dasynq does). Finally, the boost::asio multi-threading model is awkward, for reasons I try to explain here: https://davmac.wordpress.com/2016/06/18/boost-asio-and-resou...

Also:

More importantly, this is an error which can happen purely on the client side. You don't need to compromise the node itself, you just need to compromise some peer between the client you wish to attack and the node. This is a larger attack surface and potentially allows you to force a reconnect and other bad things.

I don't understand what you mean by this. There aren't any peers between the client and the node. The node (socket) is owned by some process and the client has a connection to that socket.

Or somebody closes your socket. There are several ways in which this can happen, most of them undesirable

Please tell me how a third party can close an anonymous socket connection between two processes (because if there really is a way to do that, it's a huge problem in a bunch of existing programs).

You can, for instance, pass your socket to another process and it can (maliciously) close it

That won't have any effect; if you pass a socket to another process, it's a separate file descriptor in the other process. It can't close your file descriptor, and it can't close the socket since there remains an open descriptor.

So you can't really pass your own sockets around, you need some protocol to obtain a new socket

Right; this is discussed in the blog post.

Will this new socket be closed automatically if your parent closes the socket?

No. It's an independent connection. There's no way AFAIK to have two connections to the same socket where closing one will automatically close the other, even if you did want to do that, without kernel-level changes.

The guarantee you have in an object capability system is that you can only communicate with a node if you have obtained its address (the capability to communicate) beforehand

This is also guaranteed by the file descriptor = handle model. If you don't have a file descriptor representing a channel to some particular service, you can't magically create one, not by guessing addresses or any other means.

and this causes a lot of pain in the design of distributed algorithms

Hmm, usually distributed algorithms are used for distributed nodes - to which Bus1 doesn't apply; it's for local communication only (or did I miss something important)?

Sadly, the author failed to read on the history of kdbus and AF_BUS

On the contrary, I've been following their development from the beginning, with some interest.

This is more or less what dbus currently does

Actually D-Bus multiplexes all messages, so they all pass through the message bus daemon. What I'm proposing is clearly different.

and has major issues with memory accounting

This is a valid technical point, though I'm not sure it's ever been a problem in practice and I'm not convinced it needed a whole new IPC mechanism to solve.

This is exactly how D-Bus works right now

Let me clarify: this is exactly how D-Bus conceptually works right now. In practice of course D-Bus acts as a multiplexor for the communications also. It is, however, possible to send one half of a socket pair via a D-Bus message.

Choice quote

It's strange to me how often that particular quote, which was intended to be more humorous than anything (ok - I understand if most people don't think it's funny; that doesn't mean it wasn't meant to be) - is used as some kind of evidence that my ideas are wrong on a technical level, while never providing any actual technical analyses.

As for being biased; well, I've criticised SystemD and D-Bus and a whole slew of other pieces of software, and indeed that's more-or-less what the blog was originally for, but just because I do criticise does not mean that criticism is unwarranted. Where's your technical argument?

Also some of the suggestions are downright dangerous

You give only one example, which I've rebutted below. I disagree with the assertion as a whole.

this is another failure state that you add to every single connection, and which every single client has to handle

They already have to handle the node disappearing. The only difference is that you can sever the connection from particular handles via the process containing the node/socket, if it chooses to. Otherwise, there is no difference.

I read the preceeding explanation as saying "here is a security guarantee that clients can rely on"

What particular guarantee is that? The whole point of the post was that you have the same guarantees, from a security perspective, with file descriptors.

What is the alternative? Having unix domain sockets sprinkled somewhere in the file system where everyone with the right permissions can access them?

I think you've misunderstood me. Unix domain sockets do NOT have to be associated with a path in the file system (see socketpair function). You can have some kind of arbiter process (aka the D-Bus daemon) which hands out socket connections, just as you need (with Bus1) some way of handing out handles. This is exactly how D-Bus works right now.

Maybe the ordering doesn't have to be globally consistent, but better safe than sorry.

So you build a whole new, Linux-only, IPC mechanism because it might be important to have global ordering, even though no-one's been able to identify a use case in which it matters?