The kdbuswreck [LWN.net]

The kdbuswreck

Posted Apr 25, 2015 12:27 UTC (Sat) by lsl (subscriber, #86508)
In reply to: The kdbuswreck by cortana
Parent article: The kdbuswreck

> Having selected an object to talk to, for instance, /org/freedesktop/ColorManager, you now choose an *interface*

That seems backwards to me. Why would I even care what object I talk to? I just want *some* object that implements the interface I need.

So when calling methods on the 'org.freedesktop.ColorManager' interface those get dispatched to an implementation that makes sense accorrding to local system configuration, say colord, KolorManager or whatever the user set up for this.

Is it possible to sanely use dbus this way? I mean, I can certainly enumerate the bus und search for something that implements the wanted interface but that doesn't seem reasonable.

So let's take a step back here. How would one implement the concept "I want this functionality but I don't care who provides it" in dbus? Are interfaces a red herring here and I better look at well-known names? What those resolve to is up to system configuration, right? So is this the point where it is commonly decided what program will handle my requests regarding color management? Whatever owns the name?

to post comments

The kdbuswreck

Posted Apr 25, 2015 13:34 UTC (Sat) by mchapman (subscriber, #66589) [Link] (5 responses)

> How would one implement the concept "I want this functionality but I don't care who provides it" in dbus?

I would say that is *exactly* what D-Bus provides now. There is nothing in D-Bus's policy configuration that locks a service to a particular binary. A service name can be claimed by any process that matches that service's policy (for system services this is typically just a check that the connection was authenticated as root). Of course, only one D-Bus connection can own a service name at any particular time.

Service activation is a bit different, as D-Bus (or systemd, if it's doing the activation) needs to know which binary to launch when the service is requested. I suppose you could use something like alternatives to cater for multiple implementations of that service.

The kdbuswreck

Posted Apr 25, 2015 15:17 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

> Service activation is a bit different, as D-Bus (or systemd, if it's doing the activation) needs to know which binary to launch when the service is requested. I suppose you could use something like alternatives to cater for multiple implementations of that service.

There should already be examples for this at the session level with the different NetworkManager UIs, kwallet vs. gnome-keyring, etc.

The kdbuswreck

Posted Apr 27, 2015 12:16 UTC (Mon) by javispedro (guest, #83660) [Link] (3 responses)

> I would say that is *exactly* what D-Bus provides now. There is nothing in D-Bus's policy configuration that locks a service to a particular binary. A service name can be claimed by any process that matches that service's policy (for system services this is typically just a check that the connection was authenticated as root). Of course, only one D-Bus connection can own a service name at any particular time.

You actually _cannot_ do what is being asked with current D-Bus, and it is one of my major gripes with it (which is why I prefer anything else over it). The "using the service name as what every other IPC would call interface name" idea works well until you realize you cannot register more than one service with the same name. Thus, you start seeing ugly tricks such as what MPRIS does, which require greping over the service names, etc.

The kdbuswreck

Posted Apr 27, 2015 12:54 UTC (Mon) by mchapman (subscriber, #66589) [Link] (2 responses)

> The "using the service name as what every other IPC would call interface name" idea works well until you realize you cannot register more than one service with the same name. Thus, you start seeing ugly tricks such as what MPRIS does, which require greping over the service names, etc.

I don't think it's necessarily an ugly trick. The difference between getting a list of service names with some prefix and in getting a list of services providing some object (assuming this were even possible with D-Bus) is mostly superficial.

If efficiency is the problem, getting a list of service names for things like MPRIS could be optimized by extending the protocol slightly, e.g. by having org.freedesktop.DBus.ListNames take a prefix as an argument.

But allowing a service name to be owned by at most one connection is essential for lsl's use case. You can't sanely dispatch "to an implementation that makes sense accorrding to local system configuration" if more than one such implementation is on the bus at the same time.

The kdbuswreck

Posted Apr 27, 2015 13:28 UTC (Mon) by MrWim (subscriber, #47432) [Link]

I don't think it's necessarily an ugly trick. The difference between getting a list of service names with some prefix and in getting a list of services providing some object (assuming this were even possible with D-Bus) is mostly superficial.

If efficiency is the problem, getting a list of service names for things like MPRIS could be optimized by extending the protocol slightly, e.g. by having org.freedesktop.DBus.ListNames take a prefix as an argument.

Indeed, this is the purpose of the arg0namespace match rule. You register for NameOwnerChanged events with some prefix, call ListNames (or ListActivatableNames) filtering on the prefix and then you can efficiently and asynchronously keep your local list of remote names up-to-date.

The kdbuswreck

Posted Apr 28, 2015 8:10 UTC (Tue) by javispedro (guest, #83660) [Link]

It introduces a bunch of additional problems. For example, what if you want the same process to expose more than one instance of the service? You will be hit by the fact that despite having multiple service names you still have one object namespace only... and no way to setup different policies, etc.

The MPRIS trick obviously works, but it puts the design of DBus upside down.

The kdbuswreck

Posted Apr 27, 2015 6:45 UTC (Mon) by krake (guest, #55996) [Link]

> That seems backwards to me. Why would I even care what object I talk to? I just want *some* object that implements the interface I need.

It will depend on the type of service, i.e. if there is some object related context.

For example, a service which provides functionality on a set of real world objects will expose these objects again as a set of D-Bus objects.
It makes it easier for programmers on both sides (service and clients) if there is a one-to-one mapping, e.g. NetworkManager exposing each network device as a separate object.

For a service that provides only one interface on one object, the convention seems to be to use the same name parts for the well-known connection name, the object path and the interface name (with respective separator characters).

The kdbuswreck

Posted Apr 27, 2015 7:30 UTC (Mon) by cortana (subscriber, #24596) [Link] (2 responses)

> That seems backwards to me. Why would I even care what object I talk to? I just want *some* object that implements the interface I need.

If you're saving passwords then you want to be sure that the 'org.freedesktop.secrets' address has not been taken by a password-stealing program.

The kdbuswreck

Posted Apr 27, 2015 9:06 UTC (Mon) by mchapman (subscriber, #66589) [Link] (1 responses)

> If you're saving passwords then you want to be sure that the 'org.freedesktop.secrets' address has not been taken by a password-stealing program.

That seems like a completely orthogonal problem to me.

I'm going to reiterate what I said in my other post: D-Bus *already provides* the ability for a client to talk to "any object that implements a particular interface": simply replace the word "object" with "service" and "interface" with "object".

The kdbuswreck

Posted Apr 27, 2015 9:16 UTC (Mon) by mchapman (subscriber, #66589) [Link]

> I'm going to reiterate what I said in my other post: D-Bus *already provides* the ability for a client to talk to "any object that implements a particular interface": simply replace the word "object" with "service" and "interface" with "object".

Meh, I screwed that comment up. I should have said: simply replace the word "object" with "connection" and "interface" with "service".

That is, a D-Bus client does not care what connection provides a particular service; it relies on bus policy for that to be authorized appropriately.

That being said, I have the feeling there is very little stopping some malicious piece of software from killing off gnome-keyring-daemon, say, and grabbing the org.freedesktop.secrets bus name before GNOME has a chance to restart the daemon.

The kdbuswreck

Posted Apr 27, 2015 15:17 UTC (Mon) by hp (guest, #5220) [Link] (1 responses)

> That seems backwards to me. Why would I even care what object I talk to? > I just want *some* object that implements the interface I need.

An interface is implemented by N objects, so for example an interface might be implemented by each open document in a word processor. I would say you do not want "some document that implements the Document interface" when you call `org.whatever.Document.Delete()`, you want the specific document you plan to delete :-)

*Services* are generally pluggable - i.e. the entire word processor application, could implement a set of objects (each with a set of interfaces) conforming to some sort of standard, potentially, and then you could interop with whichever word processor owns a certain `org.whatever.WordProcessor` service, or something.

Well-known name: like a DNS entry, a way to find an entire *program* to talk to (service locator)

Object path: equivalent to a pointer ... a specific instance of an object in the "object-oriented programming" sense of object

Interface: means same thing as in Java (set of methods on an object instance)

The fact that some programs have only one object instance with only one interface, in no way means that these are redundant.

Yes you can write a program in Java that only contains `class MyProgram` and `static MyProgram theInstanceOfMyProgram = new MyProgram()`.

This does not mean that Java should _only_ provide support for singleton objects!

The kdbuswreck

Posted Apr 27, 2015 18:59 UTC (Mon) by lsl (subscriber, #86508) [Link]

> An interface is implemented by N objects, so for example an interface might be implemented by each open document in a word processor. I would say you do not want "some document that implements the Document interface" when you call `org.whatever.Document.Delete()`, you want the specific document you plan to delete :-)

Ah ok, thanks. Didn't thought about it that way. For most of the stuff on my local system bus it wouldn't make a difference: it doesn't matter who tells me the hostname or who is going to set the timezone. But then there's logind (which I missed the last time), where it in fact matters whose session is going to be terminated.