[Bug 1544874] [NEW] dbus.user-session.upstart could avoid mktemp

Simon McVittie 1544874 at bugs.launchpad.net
Fri Feb 12 08:52:22 UTC 2016


Public bug reported:

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.

** Affects: dbus (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dbus in Ubuntu.
https://bugs.launchpad.net/bugs/1544874

Title:
  dbus.user-session.upstart could avoid mktemp

Status in dbus package in Ubuntu:
  New

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 manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1544874/+subscriptions



More information about the foundations-bugs mailing list