However, relocating a dbus-daemon with XDG_DATA_DIRS seems potentially useful for regression testing or whatever (which is also the intended purpose of most of the environment variables that Snap app-containers (ab)use to pretend to be a namespace, AIUI).
---
What is your use case for relocating the system bus?
The system bus is a bus for the system. Running a separate system bus in a container seems deeply inappropriate, unless the container is as close to whole-system as things like lxc and Docker, in which case the chroot-like environment will do the right thing anyway.
Comment on attachment 127303
proposed patch
Review of attachment 127303: ------- ------- ------- ------- ------- ------- ------- ------- --
-------
For the session bus, it would seem reasonable to search XDG_DATA_DIRS according to the basedir spec (<https:/ /specifications .freedesktop. org/basedir- spec/basedir- spec-latest. html>). I'd rather do that than invent a new environment variable.
I'm somewhat sceptical about the correctness of a Snap app-container running its own dbus-daemon - a contained app doesn't sound a lot like a login session to me (<https:/ /dbus.freedeskt op.org/ doc/dbus- specification. html#message- bus-types>), and this is pretty much the opposite of the direction that the "user-session" work has gone in (<https:/ /lists. freedesktop. org/archives/ systemd- devel/2015- January/ 027711. html>).
However, relocating a dbus-daemon with XDG_DATA_DIRS seems potentially useful for regression testing or whatever (which is also the intended purpose of most of the environment variables that Snap app-containers (ab)use to pretend to be a namespace, AIUI).
---
What is your use case for relocating the system bus?
The system bus is a bus for the system. Running a separate system bus in a container seems deeply inappropriate, unless the container is as close to whole-system as things like lxc and Docker, in which case the chroot-like environment will do the right thing anyway.