User bus conclusion

[David Zeuthen]

Hi,

On Tue, Nov 9, 2010 at 9:45 PM, Havoc Pennington <hp at pobox.com> wrote:
> Hi,
>
> On Tue, Nov 9, 2010 at 9:29 PM, David Zeuthen <zeuthen at gmail.com> wrote:
>> Really depends on what you mean by session. FWIW, the OS will still
>> need to be able to enumerate all user logins (roughly corresponding to
>> the existing session bus type) in addition to groups of logins
>> (corresponding to the newly proposed bus type)
>>
>>  UserOnHost(user=alice)
>>   LoginSession1(ssh)
>>   LoginSession2(LocalMonitor0, active)
>
> I guess I mean session = graphical session. I don't think anyone is
> starting a session bus right now per ssh session.

Right, no one AFAIK is currently starting a session bus on ssh login.
Which means that apps using the session bus either launch their own
bus or just bail out. So you end up with either broken apps (bad) or a
host of buses all owned by the same uid that can't speak to each other
(which again causes failures).

As a concrete example, look at GIO/GVfs. There are two interesting problems

 - system daemons have to be very careful to avoid starting GVfs
   because
   - it means launching a dbus-daemon(1) instance _per_ process trying
to use it.
   - GVfs is inherently tied to (user, machine) - for example, the FUSE mount

 - ditto for ssh(1) logins

It's actually so bad that we have this code in GVfs:

 http://git.gnome.org/browse/gvfs/tree/client/gdaemonvfs.c?id=1.6.5#n1563
 http://git.gnome.org/browse/gvfs/tree/monitor/proxy/gproxyvolumemonitor.c?id=1.6.5#n1229

that specifically disables the GVfs daemons unless a session bus has
been started (and this fact is communicated via the environment
variable). It's really bad that we need to do this and there is no
real way around it (except for moving GVfs to the newly proposed bus,
of course).

A lot of things are really like GVfs - e.g. a lot of OS services are
tied to the (user, machine) and not the login-session. Other things
than VFS include e.g. settings/preferences, keyring, address book
services and so on.

At the same time, some things are really tied to the login-session and
NOT the (user, machine) pair. This includes e.g. notification
services, authentication dialog services and other things. For
example, the org.freedesktop.Notification service _cannot_ use the
newly proposed user bus... unless you implement it in a way so it
somehow displays the message on all login-sessions owned by the user..
including ssh and X ones.. messy.. e.g. instead you'd just run a
org.fd.Notification service on each login-session (including,
possibly, a textual one per ssh(1) login session).

>> FWIW, I don't think it's helpful changing the session bus scope -
>> especially not as it's already defined in the D-Bus spec (as being
>> one-to-one with the (X server instance, uid) pairs).
>
> The spec as I'm reading it seems to be really vague and unclear.... in
> any case, I think the main thing apps/services might rely on is that
> there's only one X server on the session bus (and that they should
> exit along with the session bus). If that's all they depend on you
> won't really be breaking anything.

Actually, Thiago recently committed fixes for that, see

 http://cgit.freedesktop.org/dbus/dbus/commit/?id=b17a5f852c12b653fe892948ed2ead421f57ed97

and even if that wasn't the case, I still don't think it's kosher to
change this as you would be breaking existing code - for example the
org.freedesktop.Notification service as mentioned above. Or desktops
where multiple graphical logins really work (for real, or otherwise).
I really don't think we can do that. You'd also be breaking 3rd party
implementations already mimicking whatever libdbus-1 is doing to get
the session bus address (e.g. looking at X11 properties).

The main point, I think, is that the newly proposed USER bus and the
existing SESSION bus are two different things. Sure, adding a new bus
type adds complexity but the world _is_ that complex.. e.g. GVfs and
org.fd.Notifications are two very different users of D-Bus.. the
former _really_ wants the (user, machine) thing and the latter really
wants to be run _per_ login session (including ssh(1) logins)... I
don't see the point in hiding this complexity. Instead, we should
embrace it and explain people, by example, how and when to use the
various bus types.

     David