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@xxxxxx> http://people.redhat.com/djr/ Desktop Tools
|
