D-Bus User Bus
mzqohf at 0pointer.de
Mon May 24 14:55:34 PDT 2010
On Wed, 19.05.10 23:33, Havoc Pennington (hp at pobox.com) wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=17970#c23 may be a more
> useful comment with the "possible direction" options.
Well, I'd go a different direction, let's call it "Possible direction 4":
Concept: Every pair ($HOME,$MACHINE) gets its own session, and multiple
sessions can connect to the same display, as well as one
session can connect to multiple displays.
* A dbus session can only have one $HOME. Apps may rely that sending a
file path over the bus allows the other side to access it, both
namespace-wise and permission-wise.
* A dbus session can only have one $MACHINE. Apps may rely that sending a
device if in some way over the bus allows the other side to access it,
both namespace-wise and permission-wise.
* D-Bus singletons should include the display identifier if they want to
be startable on more than one display at a time.
* logout notification for displays should be done via X11, not via
D-Bus. If a display goes away when an app is still talking to it, it
will be terminated by libx11 or libgtk from within the process.
* both su and remote ssh logins would talk to different session
busses. Other machines and other user would be blocked from accessing
the local bus.
* If you log in as normal user, and then run thunderbird as root via su,
and follow a link there you will get a new firefox instance started as
root, it won't end up in the already running instance of your own
* If you run "ssh -X foo firefox" and then "ssh -X foo thunderbird"
they'll get the same session bus on the machine "foo".
With this scheme, things would be reasonably safe, and people are safe
to continue making the assumptions about path namespacing/permissions
they are making already.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the dbus