D-Bus

Bug #328575
Comment #19

Comment 19 for bug 328575

Revision history for this message

In freedesktop.org Bugzilla #17970, Colin Walters (walters) wrote on 2009-02-10:

#19

I've changed my mind on this bug slightly - I'll now argue that what the session bus should be strongly tied to is $HOME, but the X server can vary.

(In reply to comment #17)
> What I'm saying is basically that whenever xauth is forwarded to another user,
> the dbus auth needs to also be forwarded. These two should never be out of
> sync.
>
> If not wanting to hack su or pam or whatever, one approach is to add an X-based
> auth mechanism to dbus (store a cookie on the X root window or something like
> that).
>
> Adding crazy hacks here is probably going to end in tears. The only sane model
> is that the session is defined by dbus and X, and 1 bus goes with 1 X server
> ...

What I'd say is that's the most obvious and well defined model. But let's consider what happens right now if you use "ssh -Y" to some server and run Firefox (and people do this). What happens today is that Firefox is able to connect to your X server, but when Firefox tries to access DBUS_BUS_SESSION, none exists, so libdbus auto-spawns one. This results in two session buses on two different machines, and one X server.

How *should* the ssh -Y case work? Do we say "don't do that"? Teach ssh how to forward dbus back to the local session? (Note this only works if running freedesktop on the client, if you're using one of those X-on-MS-Windows programs it will obviously fail.)

Now, I will argue that the ssh -Y use case is broken, and what we really want is something like VNC with client side fusion-type integration. However - we can't actively break the legacy behavior here. People expect "ssh -Y myserver firefox" to not break.

The other major case here is "sudo gedit", which is the original bug report. Here again, people expect this to work; we can't just say "don't do that". My suggestion is that we make this case match the ssh case by creating a second session bus (implemented by ignoring the existing DBUS_SESSION_BUS_ADDRESS because of a uid mismatch).

In both of these cases now, the session bus the application sees matches the machine $HOME is seen from, which I think is right.

I've changed my mind on this bug slightly - I'll now argue that what the session bus should be strongly tied to is $HOME, but the X server can vary.

(In reply to comment #17)
> What I'm saying is basically that whenever xauth is forwarded to another user,
> the dbus auth needs to also be forwarded. These two should never be out of
> sync.
> 
> If not wanting to hack su or pam or whatever, one approach is to add an X-based
> auth mechanism to dbus (store a cookie on the X root window or something like
> that).
> 
> Adding crazy hacks here is probably going to end in tears. The only sane model
> is that the session is defined by dbus and X, and 1 bus goes with 1 X server
> ...

What I'd say is that's the most obvious and well defined model.  But let's consider what happens right now if you use "ssh -Y" to some server and run Firefox (and people do this).  What happens today is that Firefox is able to connect to your X server, but when Firefox tries to access DBUS_BUS_SESSION, none exists, so libdbus auto-spawns one.  This results in two session buses on two different machines, and one X server.

How *should* the ssh -Y case work?  Do we say "don't do that"?  Teach ssh how to forward dbus back to the local session? (Note this only works if running freedesktop on the client, if you're using one of those X-on-MS-Windows programs it will obviously fail.)

Now, I will argue that the ssh -Y use case is broken, and what we really want is something like VNC with client side fusion-type integration.  However - we can't actively break the legacy behavior here.  People expect "ssh -Y myserver firefox" to not break.

The other major case here is "sudo gedit", which is the original bug report.  Here again, people expect this to work; we can't just say "don't do that".  My suggestion is that we make this case match the ssh case by creating a second session bus (implemented by ignoring the existing DBUS_SESSION_BUS_ADDRESS because of a uid mismatch).

In both of these cases now, the session bus the application sees matches the machine $HOME is seen from, which I think is right.