The kdbuswreck [LWN.net]

The kdbuswreck

Posted Apr 25, 2015 20:38 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
In reply to: The kdbuswreck by kentonv
Parent article: The kdbuswreck

For example, the path "/org/freedesktop/ColorManager/devices/printer1" refers to the *same* file regardless of who is opening it. The problem with this is that it means the calling code decides which file to open. That's bad because:

1. It's probably the user, not the app, that knows best which file to open. So now the app needs to implement a picker dialog. Many apps will skip this and just hard-code the first file. (In practice you don't usually see this problem for files, but you *do* see it for, say, audio output devices. Every app that plays audio should be asking me which device to use, but, sadly, they do not. I must choose a system-wide default device, and I cannot easily have different apps playing to different speakers. Yes, some systems support advanced configuration of audio sources and destinations within the audio control panel, but my point is that we should have this kind of configurability for all resources.)

2. The app necessarily has the ability to enumerate the files and open all of them. For security reasons, it would be better if the app *only* had the ability to open the file that I, as the user, chose for it to access. Traditionally desktop systems have made the unfortunate assumption that I trust all my apps to wield all the power of my user account, but I'd really prefer that each of my apps runs in a sandbox with only the power it needs to do its job.
...

> What I want is for apps to make requests like "I need something that implements org.freedesktop.AudioOutput" (or whatever interface), and then the system displays a dialog to the *user* asking which device or service to use.
Try to watch DBUS with a sniffer. Now imagine that you have to MANUALLY select each and every endpoint.

to post comments

The kdbuswreck

Posted Apr 25, 2015 21:03 UTC (Sat) by kentonv (subscriber, #92073) [Link] (5 responses)

> Try to watch DBUS with a sniffer. Now imagine that you have to MANUALLY select each and every endpoint.

Yes obviously what I'm describing can't be dropped on top of the existing set of dbus endpoints and just work. Lots of stuff would need to be redesigned and organized differently. It is possible to design such an environment and have it work well (CapDesk did it, and Sandstorm.io is doing it), but I don't honestly expect today's dbus-using desktop environments to entirely switch anytime soon. Still, it's useful for people to understand the ideal in order to guide improvements to what we have today.

The kdbuswreck

Posted Apr 25, 2015 22:42 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

I still have no idea how your design will be any different from the current one. You still need to have well-known starting points for lookups.

The kdbuswreck

Posted Apr 26, 2015 20:17 UTC (Sun) by luto (subscriber, #39314) [Link] (1 responses)

Not really. Yes, something needs to create a starting point, but that something could just be whatever creates the resource in the first place.

For example, gdm or logind could start my shell with access to an object implementing the "find a printer" interface. Programs that inherit access to that object would use it.

Sandboxed programs, on the other hand, might get access to a different "find a printer" interface that behaves differently.

dbus can do this right now. On my Fedora 21 system, my shell and everything it starts has access to a standard implementation of a lot of these things. It looks like:

DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-qB3T8DFwej,guid=1453a3565ca58487e6a024fe5538ad89

Too bad that doesn't seem to apply to the system bus.

The kdbuswreck

Posted Apr 27, 2015 4:12 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

There's nothing really special about the system bus. It's possible to override it for each application.

But as I understand, it was designed to be a globally visible namespace with access being controlled by PolKit.

The kdbuswreck

Posted Apr 26, 2015 20:19 UTC (Sun) by kentonv (subscriber, #92073) [Link]

The "starting point" would be a file descriptor inherited from the parent process. Today we have "standard input", "standard output", and "standard error"; now imagine adding "standard desktop" which is a socket that implements some protocol to talk to the desktop session.

This file descriptor would support a bunch of standard functionality that all apps need (like, opening windows, or raising notifications, etc., but NOT things where the user might want to choose the resource used or deny it for security reasons, like printers or audio devices or connected OAuth accounts). It would also have a way to say "I need an object (file descriptor) implementing protocol X", and that's when the user is prompted to choose which object to use. Once the user chooses something, the app can save a long-term token representing that choice and re-request the same object later using that token.

Yes, this is "standard desktop" FD is similar to the dbus session bus, except that I can decide which programs that I run are allowed to access it, and I can mock it out, audit usage, sandbox, etc., as described previously, and I can make choices about individual resources accessed by any app.

The kdbuswreck

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

Yes, but you can make symlinks ;)