dbus-daemon has an --address parameter where a known address could be given, e.g.:
dbus-daemon --nofork --address "unix:abstract=$XDG_RUNTIME_DIR/dbus" --config-file=/usr/share/defaults/at-spi2/accessibility.conf
and DBUS_SESSION_BUS_ADDRESS could be set to it in the env. for services that need a connection to the dbus session. but how to set the env. variable? I don't really want to have special code just for managing dbus like this...
an example of a service file for dbus that uses a consistent address location:
[Unit] Description=DBus user session service [Service] Type=simple ExecStart=dbus-daemon --nofork --address unix:path=$XDG_RUNTIME_DIR/dbus.sock --session Restart=always RestartSec=1Then you might do something like:
$ superctl set-env DBUS_SESSION_ADDRESS="unix:abstract=$XDG_RUNTIME_DIR/dbus.sock"and restart the services that need dbus after that service starts... but that's not ideal for obvious reasons
I've seen quite a few clients default to
unix:path=$XDG_RUNTIME_DIR/busif$DBUS_SESSION_BUS_ADDRESSis unset (Telegram / Qt comes, IIRC). It seems to be a standard thing, from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836117 :In recent libdbus and GDBus, the fallback behaviour if DBUS_SESSION_BUS_ADDRESS is unset is to look for $XDG_RUNTIME_DIR/bus: if the environment variable is set, that directory contains ./bus, and ./bus is a socket owned by the current uid, then libdbus and GDBus will automatically use it.
Perhaps that would be the recommendable value here?
abstractsocket is not a good idea; it's too easy to overlook when sandboxing (since it's not a regular socket/file).
On Thu, 17 Nov 2022 23:48:02 +0000 "~whynothugo" outgoing@sr.ht wrote:
I've seen quite a few clients default to
unix:path=$XDG_RUNTIME_DIR/busif$DBUS_SESSION_BUS_ADDRESSis unset (Telegram / Qt comes, IIRC). It seems to be a standard thing, from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836117 :In recent libdbus and GDBus, the fallback behaviour if DBUS_SESSION_BUS_ADDRESS is unset is to look for $XDG_RUNTIME_DIR/bus: if the environment variable is set, that directory contains ./bus, and ./bus is a socket owned by the current uid, then libdbus and GDBus will automatically use it.
Perhaps that would be the recommendable value here?
abstractsocket is not a good idea; it's too easy to overlook when sandboxing (since it's not a regular socket/file).Ah, thank you for pointing that out! I agree, it is a good idea to use that by default if the var is unset, especially if there is some precedence for other apps doing it too.
-Clayton
I've experimented with a few apps unsetting the variable and that path just works. I still haven't unset it session wise to see what breaks.
On Fri, 18 Nov 2022 00:05:54 +0000 "~whynothugo" outgoing@sr.ht wrote:
I've experimented with a few apps unsetting the variable and that path just works. I still haven't unset it session wise to see what breaks.
Would you be interested in submitting a patch to set that path as the default if the var is unset when superd starts?
I'd rather not set the variable at all. Just run D-Bus in the "well known" default path.
Most applications should detect the socket and run fine; if any applications don't, it'd be ideal to report that upstream.
The approach can be revisited if it turns out that lots of applications out there DO break.
The biggest blocker here is readiness notification. We can't just start other services after dbus has been started, we need to confirm that dbus itself is ready to serve clients first.
Some applications don't actually use this well-known fallback. Relevant: https://gitlab.freedesktop.org/dbus/dbus/-/issues/449