[systemd-devel] Compatibility between D-Bus and kdbus

[Lennart Poettering]

On Tue, 25.11.14 18:46, Thiago Macieira (thiago at kde.org) wrote:

> On Wednesday 26 November 2014 00:46:50 David Herrmann wrote:
> > We had "systemd-bus-driverd", which implemented org.freedesktop.DBus
> > as normal service. However, this didn't work out as many dbus clients
> > rely on this services to not be re-ordered in regard to external
> > requests.
> > 
> > In particular, if gdbus runs AddMatch(), it assumes the match takes
> > effect immediately. If it sends a method call to another service after
> > installing the match, and this triggers a signal, gdbus assumes the
> > AddMatch() call to have succeeded (without waiting for the reply).
> > However, if org.freedesktop.DBus is not implemented by the bus, but by
> > an external service, you cannot guarantee that messages targetted at
> > different receivers don't get re-ordered, and there're no guarantees
> > which process gets scheduled first.
> > 
> > This is a real bug and we couldn't figure out a way to fix it. Current
> > DBus applications depend on org.freedesktop.DBus to be handled by the
> > bus entity _in-order_. Therefore, we dropped systemd-bus-driverd and
> > all the kdbus ioctls that we added to support this.
> 
> Aside from the connection-control mechanisms (AddMatch, RemoveMatch), did you 
> see any problems?

It was primarily about that, but it is easy to construct races with
this for most of the other driver calls as well.

The race is very real btw. Because a frequent pattern is to establish
a match, then invoke some method on some random service. However, with
doing the driver in a separate service it might happen that the method
call is processed before the driver finds the time to process the add
match request. And then, any signals sent out by the service
processing the method call might not be subject to the added match...

> User code usually shouldn't be doing AddMatch and RemoveMatch (the only case I 
> can think of is dconf, which does its own parsing of the message payload). 
> That's the domain of the binding, which will know that it connected to kdbus 
> and won't be making those calls.

Well, I am sure that in many cases apps want to install their own
matches, beyond the object model of the used framework. For example, a
graphical UI for systemd might want to subscribe to all of systemd's
signals without actually matching on any specific object. Most
framework object models don#t cover that. Or think of a tool like
d-feet that wants to subscribe even more liberally, per service...

> > Custom endpoints do _not_ create new buses. Really. You could create a
> > custom bus and use it for just 2 connections, but then you could also
> > just use socketpair(2). Note that there was some discussion on
> > "anonymous buses", which would allow to create such buses on the fly.
> > But again, this will not be part of the initial kdbus draft. If anyone
> > cares, submit it as patches once kdbus is upstream.
> 
> As far as I can tell, an "anonymous bus" in the sense of a bus with a 
> randomised name is doable by having the proper interface in the systemd1 
> system bus service. An application would request the bus and receive as a 
> reply the address of the bus, the file descriptor for the control, and a file 
> descriptor to a privileged connection so it can control the
> policies.

No need to involve systemd. Creating additional busses requires no
priviliges. You can just invoke the ioctls directly.

Lennart

-- 
Lennart Poettering, Red Hat