[patch] Auto session bus launch from libdbus

[Havoc Pennington]

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:
  char* dbus_connection_get_remote_machine_id()
  char* dbus_get_local_machine_id()

and for convenience:

   dbus_bool_t dbus_connection_is_on_same_machine()
   {
      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 
the problem.

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.

Havoc