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
Touch seeded packages, 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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
