dbus.user-session.upstart could avoid mktemp

While investigating a separate bug I happened to look at dbus.user-session.upstart, and noticed that it is somewhat more complex than it needs to be.

> pre-start script
> DBUS_SESSION_BUS_ADDRESS=unix:abstract=$(mktemp -u /tmp/dbus-XXXXXXXXXX)
> initctl set-env DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS
> end script
>
>
> exec dbus-daemon --fork --session --address="$DBUS_SESSION_BUS_ADDRESS"

One obvious simplification you could use here would be to ask dbus-daemon to listen on an arbitrarily selected abstract AF_UNIX address and tell you which one it used. In principle libdbus could have a retry loop to try multiple possibilities if the one it selects first is in use (which this use of mktemp obviously won't do); at the moment it doesn't, because the probability of a successful DoS by creating lots of abstract sockets is low (approximately n in 3e15, where n is the number of sockets created by an attacker), but I'd review a patch to dbus/dbus-server-unix.c if someone wanted to add that retry loop.

That would look something like this (please interpret this as pseudocode rather than a proposed patch, I don't actually know Upstart syntax):

    exec script
        # the default listening address is equivalent to --address=unix:tmpdir=/tmp
        dbus-daemon --fork --session --print-address=5 5>"$XDG_RUNTIME_DIR/dbus-session"
    end script

    post-start script
        DBUS_SESSION_BUS_ADDRESS="$(cat "$XDG_RUNTIME_DIR/dbus-session")"
        initctl set-env --global DBUS_SESSION_BUS_ADDRESS="$DBUS_SESSION_BUS_ADDRESS"
        initctl notify-dbus-address "$DBUS_SESSION_BUS_ADDRESS"
    end script

which is already somewhat simpler. This would also have the advantage that the advertised address would contain the bus's GUID like it does with traditional dbus-launch, meaning that dbus_connection_open() would work (<https://bugs.freedesktop.org/show_bug.cgi?id=94085>).

However, since the current script only seems to support one dbus-daemon per $XDG_RUNTIME_DIR anyway, there's little point in using mktemp or unix:tmpdir: the job could instead force a specific address, like the systemd unit in dbus-user-session does. Modern libdbus (1.10+) and GDBus (2.45.3+) will try $XDG_RUNTIME_DIR/bus if there is no DBUS_SESSION_BUS_ADDRESS, so setting the DBUS_SESSION_BUS_ADDRESS is really only there to support reimplementations like dbus-sharp.

    exec dbus-daemon --fork --session --address="unix:path=$XDG_RUNTIME_DIR/bus"
    post-start initctl set-env --global DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"
    post-start initctl notify-dbus-address "unix:path=$XDG_RUNTIME_DIR/bus"

(This could be combined with --print-address if you want to know the full address with the guid.)

Or, if the intention is to support multiple login sessions per user-session (see <https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html> for terminology), the Upstart job could force the bus to be "$XDG_RUNTIME_DIR/session-$XDG_SESSION_ID/bus" or something.