The kdbuswreck [LWN.net]

The kdbuswreck

Posted Apr 25, 2015 21:03 UTC (Sat) by kentonv (subscriber, #92073)
In reply to: The kdbuswreck by Cyberax
Parent article: The kdbuswreck

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

to post comments

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 ;)