D-Bus User Bus

[Lennart Poettering]

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

* 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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4