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

Lennart Poettering mzqohf at 0pointer.de
Wed Nov 26 10:44:46 PST 2014

On Wed, 26.11.14 10:10, Thiago Macieira (thiago at kde.org) wrote:

> On Wednesday 26 November 2014 12:35:33 Lennart Poettering wrote:
> > > 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.
> [snip]
> Can you explain, if you remember, how the race could happen for the other 
> driver calls?
> Is this one: GetConnectionUnixProcessID could return stale information because 
> the process has exited by the time that the reply arrived. If so, this race 
> already existed in dbus1.

Here's are two examples:

First: AcquireName(): you issue issue an async request for acquiring
"foo.bar", and immediately send a message to it. On dbus1 this will
work: the bus will first process the AcquireName(), and then deliver
the message back to you given that you now have the name. In a kdbus
design with an extern driver process the AcquireName() call would be
passed to the driver, and the next message most likely be processed
before the driver processes it, thus most likely resulting in a
delivery failure of the second message.

Now, that's the reason why acquirename/releasename need to be
implemented client side. With that knowledge we can punch holes in the
other calls too. For example, the GetConnectionUnixProcessID() call
you brought up: let's now issue a GetConnectionUnixProcessID() async
first, immediately followed by an AcquireName() for the same name. On
dbus this will tell you the old owner, and then acquire the name for
you. On kdbus with an external driver this would be different
though. While the GetConnecitonUnixProcessID() is queued and waiting
to be processed the AcquireName() might already have been executed
(because it needs to be an ioctl as we have shown above), hence you
would get your own PID returned, not the old one!

hence, this calls really should be sync local ioctl()s, not half-half...


Lennart Poettering, Red Hat

More information about the dbus mailing list