[patch] Auto session bus launch from libdbus
hp at redhat.com
Sun Sep 10 16:52:13 PDT 2006
Havoc Pennington wrote:
> An approach (other than the X property that avoids some of this mess
> ;-)) might be to have dbus create a per-machine guid at install time.
> This is just a useful thing to have available anyway, I've been thinking
> of adding it to the system bus. Then if we parsed the ":N" part out of
> DISPLAY and appended it to the machine guid I believe it is pretty robust.
A possible advantage of the guid thing is that each connection can have
a GetMachineId method (reads machine id from where the app is running),
and libdbus can have both:
and for convenience:
return strcmp(get_remote_id(), get_local_id) == 0;
The GetMachineId method can be implemented in DBusConnection, like the
current Ping method.
This might allow apps to behave more sanely in the remote ssh case, i.e.
if the app thinks it wants to use power management but the bus (and
therefore session) isn't on the local machine, it could avoid doing so.
Most apps will not get this right out of the box, but at least if the
app author got a bug report, they would have some way to (try to) fix
There's already the connection_get_unix_user which can be used for the
case of running an app after an "su"
Again I can't imagine most apps checking this the first time they are
implemented, but if someone reported a bug they could hypothetically
then fix the problem.
Hmm, though right now we may well reject authentication by the su'd
user, which would lead to autolaunch even if DBUS_SESSION_BUS_ADDRESS is
set. Which is probably right, there are lots of issues with having
someone else on your session bus.
For the remote ssh case, all the examples I can think of are probably
best handled by connecting to the original bus back on the first
machine. So that's an argument for doing DBUS_SESSION_BUS_ADDRESS
forwarding along with DISPLAY.
We might try then to make the default behavior be - on su, you get a new
bus for the su'd user; on ssh, we forward the existing bus. Obviously
this last requires ssh changes...
Oh! Another thing we can do with the machine guid - apps can include it
in their bus names. This allows per-(machine,session) scoping of
activated applications. Unfortunately it breaks auto-activation unless
we add some kind of feature for marking this convention in the .service
file. But, this may well be the right thing for the various
hardware-related daemons and what have you.
A final thought, each bus already has a bus guid; the bus guid of the
system bus, when the system bus is running, is effectively a per-machine
identifier (though not persistent across reboots). Unfortunately we
probably can't make the session bus rely on having a system bus running,
so we'd need a separate machine guid.
More information about the dbus