D-Bus User Bus

[Rémi Denis-Courmont]

Le vendredi 14 mai 2010 21:56:44 Lennart Poettering, vous avez écrit :
> I used to be a proponent of a user bus, and in fact I still have a
> checkout lying around here which implements most of the logic of a user
> bus. However I have since changed my position on this and am now more
> siding with Colin who wants to redefine the current session bus a little
> so that it becomes a more of a user bus. A seperate per-session bus is
> unnecessary if we have a per-user bus; instead of seperating services of
> session via the notion of multiple busses, we should seperate them via a
> display id of some kind in the bus names (if necessary at all).

Heck no. I don't want to code $DISPLAY in every DBus-enabled applications. 
Looking at my current session bus, I can see plenty of things that belong in 
my current session (mostly org.kde, but also org.freedesktop and 
org.videolan).

If GNOME is broken, fix it.

> - the current separation between sessions of the same user has no value
>   for security purposes: security sandboxing on the lower levels happens
>   along user id priviliges, not session ids. If a user cannot trust
>   himself, who can he trust?

Sure.

> - the current separation between sessions of the same user has little
>   value for the lifecycle of sessions: UI programs terminate anyway when
>   X goes down, from inside libX11; and even if that limitation might be
>   removed one day, the default for UI programs should and will continue
>   to be that they quit when the display server goes away. And anyway,
>   gnome-session should determine the life-cycle of the UI services, not
>   dbus.

For the record, XCB, and XLIB-XCB with XCB error handling do not do that.

> - generally, we should emphasize sharing of data between sessions of the
>   the same user. Ideally we'd even allow copy/paste between them.

I would disagree with that. If I open a video file in one session, I don't 
want it played in an existing instance of a media player in another session. 
Same goes for cut&paste.

> - it is a simple fact that currently only a handful of gnome
>   applications can safely be run on multiple graphical logins in
>   parallel. IIRC kde's session manager actviely disallows multiple logins
>   by the same user. Instead of miserably failing Gnome apps should be
>   more explicit about this, too i guess.

Fix broken apps, or at least have them handle error casess properly.

> - I think it is love's labor's lost to ask each and every UI program to
>   be fixed for multiple parallel logins of the same user. Teaching every
>   programmer about the intricacies just doesn't scale. Also the value
>   is minimal, since all desktop environments support virtual desktops
>   anyway.

It's going to be worse with only a user bus. Those applications that do work 
today will break as they fail to namespace the bus names. In fact, there will 
be an incenvitive not to do the $DISPLAY thing, to keep it simple for DBus 
"clients".

> - adding another bus complicates an already complex system where new
>   users already have a hard time grasping the difference between the
>   system and session bus

Your software has a more severe problem if your end user need to know what 
DBus is.

> - we already have a lot of services on the bus and moving them from one
>   to the other won't be fun, if we want to keep compat.

On my desk, all of those services belong on the session bus.

> - the current scheme does not care at all for SSH logins (or console
>   logins).

Could be fixed.

>   Nor does it cover cronjobs.

Nor does the user bus. You probably don't want all crontab users having their 
bus lying around all the time, regardless of which is actually logged on. And 
the main use case for cron is precisely to run things while not logged.

> - currently, all out busses are per-machine, however the specs leave
>   that open, so that busses could in theory be redfined to be
>   network transparent in case of NFS $HOME or networked X11
>   displays. However I think this is not
>   realistic to achieve. Again, many programs are simply not up for it,
>   for example because they assume that the FS namespace is identical on
>   the bus client and the bus server. That could often be fixed but this
>   would also have a perfomance cost since it would require data to be
>   shoved through the bus itself. Then, there's the fw issue: there's no
>   sane way to even get a TCP connection reliably established between the
>   machine running the X11 display and the app. Finally, let's not forget
>   that the emphasis of networked computing is more on VNC these days,
>   less on X11.

That's an argument against network transparency.
It's orthogonal to the scope of the bus.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis