DBUS outside of the traditional desktop; user bus; RFC

[Daniel Reed]

A session in an X desktop is tied to one login path. When a user logs in, 
their login scripts are executed before any other software in the "session" 
is brought up. These scripts are able to set variables that will be present 
in the environments of all software run in that session.

A session using consoles or external SSHes may span multiple login paths; it 
may span multiple independent virtual terminals. To add new terminals, the 
user logs in again on different virtual terminals. No one login script is 
executed "before" all other software; there is no opportunity for a variable 
to be set in the environments of all software run in that user's "session".


Use of the DBUS session bus depends on an environment variable being set to 
point software to the user's session bus. By setting the per-session bus 
environment variable during login, DBUS is able to configure a per-session 
bus for X desktop sessions without problem. For console sessions, however, 
this is not the case.


Rather than changing how the session bus is setup, I would like to propose 
adding a third standard bus, possibly named the "user bus". This could 
eventually be similar in accessibility as the system bus and session bus.

The user bus could be used by all processes owned by the same uid, 
potentially spanning multiple ideological "sessions" owned by the same user. 
Since there is no necessary environmental inheritence between processes 
owned by one user (especially if they are started from separate login 
shells), some method of distributing the DBUS bus address other than the use 
of environment variables is needed.

A simple scheme could be used like creating a session-style bus and storing 
the address in a file somewhere, for example /tmp/dbus-$USER or 
~/.dbus-user-address. However, these schemes may not be very practical in 
hostile environments without a fair bit of added complexity.

A somewhat more elaborate scheme for publishing the address of the user bus 
could be to use the system bus itself. A daemon could be started at boot, 
right after dbus-daemon-1 --system, to listen for requests to set per-user 
bus addresses and later retrieve them. DBUS API routines exist to check the 
UNIX uid of the process at the other end of an RMI, so such a daemon would 
only need to accept and store an arbitrary string from a "setBusPath" call 
(using the UNIX uid of the caller as the table key) and return the arbitrary 
string in response to a "getBusPath" call.[*]


One benefit of a user bus separate from a session bus could be realized by 
long-running processes. Certain types of network clients or CPU-intensive 
programs could be launched and attach to the user bus, able to survive the 
session from which they were launched being shut down. For example, a Galago 
client could be launched to run in the background and survive the user 
logging out for the evening without needing to log off from network 
services, shut down, and start back up again when the user next logged in.

Eventually, for login types that do not really support the notion of a 
"session bus", it could be that requests to connect to the session bus fall 
back on the user bus.


* A quick proof-of-concept hack is available at
 	http://people.redhat.com/dreed/dbus-user-0.3.tar.bz2

Untar, then:
./configure --prefix=/usr --sysconfdir=/etc && make install
killall -HUP dbus-daemon-1	(to load the user.conf file in the system bus)
/usr/bin/dbus-user		(this can be added to /etc/rc.d/rc.local)

When you next log in, an environment variable $DBUS_USER_BUS_ADDRESS will be 
set. You can use dbus-monitor --address $DBUS_USER_BUS_ADDRESS to monitor 
the new bus[1], then bind to it passing getenv("DBUS_USER_BUS_ADDRESS") into 
dbus_connection_open() in new clients.

[1] See https://bugs.freedesktop.org/show_bug.cgi?id=2432 for --address patch

-- 
Daniel Reed <n at ml.org>	http://people.redhat.com/djr/	Desktop Tools