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

[Thiago Macieira]

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.

> > 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...

As I said, the only case I've seen so far was dconf and that's only because I 
allowed it to get access to the DBusConnection pointer that QtDBus uses. And 
that's why I am not worried about its AddMatch use-case because it will get 
broken by not using DBusConnection in the first place.

In all other cases, QtDBus does not allow an application to subscribe to any 
message directly. The only way to subscribe to a set of signals is to use the 
QtDBus API, which means QtDBus will manage the match rules for you and make 
the delivery.

In any case, I am not asking for AddMatch/RemoveMatch.

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

See other email. I was assuming that /sys/fs/kdbus/control could only be 
opened by root.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358