User bus conclusion

Mike Gorse mgorse at novell.com
Tue Nov 9 17:17:35 PST 2010


How would applications that su to root tie into this?  If a user becomes 
root, would the existing user bus continue to be used?

Thanks,
-Mike

On Tue, 9 Nov 2010, Ryan Lortie wrote:

> Hi,
>
> At the Boston summit I had a chance to sit down with Lennart and discuss
> the mess we've been going over for the past while.  We came to a strong
> conclusion on all points.
>
> We also discussed the conclusion we reached with some others in
> attendence and got some rather positive feedback.  I'm going to attempt
> to document the conclusion here, but I may get some things wrong or
> leave some things out.
>
> The most significant take away is that we will add a "user" bus to DBus.
> This bus will be defined as scoped to one user on one machine.  Multiple
> logins of the user to the same machine will share the same bus.  systemd
> will be managing this.
>
> The bus will listen at a well-known path relative to the user's runtime
> directory.  See:
>
> http://lists.freedesktop.org/archives/xdg-list/2010-November/011681.html
>
> The path will be "$XDG_RUNTIME_DIR/dbus/user_bus_socket".
>
> In systemd style, the user bus won't be started until someone actually
> tries to the connect to the socket.  If you ssh in, for example,
> probably DBus won't be started, but if you try to use it then it will.
>
> DBus client libraries should add knowledge of this new bus type.
>
>
> That's it in terms of changes to DBus.  What follows is a list of
> changes that we recommend will occur to the system as a result.  Of
> course, that's up to vendors and distributors.
>
> - we recommend the session bus will no longer be started
>
> - we recommend that the DBUS_SESSION_BUS_ADDRESS environment variable
>   be set to the socket of the user bus (to support old DBus client
>   libraries and/or applications)
>
> - maybe eventually DBus client libraries can issue deprecation warnings
>   to stderr about session bus use by applications
>
> - the DISPLAY environment variable will be unset
>
>   It needs to be this way when you consider that X may not be running
>   at all when the user dbus first starts (in response to an ssh
>   session, for example).
>
> - libX11 (and xcb?) will be modified so that an unset DISPLAY
>   environment variable means that the client opens the socket
>   "$XDG_RUNTIME_DIR/X11/socket" or such.
>
>   This has the nice effect that we can use systemd to autostart a
>   rootless X server on-demand in our post-wayland existence.
>
> - on login (for now) this will be a symlink to the one in /tmp
>
> - we are against people doing tricks like "org.domain.MyApp1",
>   "org.domain.MyApp2", etc. to support app uniqueness on multiple
>   displays.
>
> All of this means that there is only one graphical login per user.
>
> I think Lennart is planning to do most of the work and I'm going to be
> helping with some small details; I've already made a couple of
> glib/GDBus patches, for example.
>
> Cheers
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>


More information about the dbus mailing list