dbus.user-session.upstart could avoid mktemp

Bug #1544874 reported by Simon McVittie
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
dbus (Ubuntu)
New
Undecided
Unassigned

Bug Description

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.