[Suggestion] Expose system bus socket to container

[PureTryOut]

Is your feature request related to a problem? Please describe.
I currently want to use an application in a distrobox container that requires access to the system bus. To do so it tries to access /var/run/dbus/system_bus_socket which exists on my host but is not available within the distrobox container.

Describe the solution you'd like
/var/run/dbus/system_bus_socket to be mounted inside the container.

Describe alternatives you've considered
Uh, none.

Additional context
In this case the application is a Flutter one using Canonical's dbus package, I doubt that matters though.

[89luca89]

This sadly is incompatible with a lot of situations, like apt trying to fire up systemd inside the containers, if that path is found

Alternatively you can set DBUS_SESSION_BUS_ADDRES=unix:///run/host/var/run/dbus/system_bus_socket and that application will access the system socket on host

[Newbytee]

For anyone else just copying this verbatim without thinking about it in the future, I had to do DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/host/var/run/dbus/system_bus_socket for this to work.

Changes:

1. There are two typos in the original variable name (SESSION instead of SYSTEM and ADDRES instead of ADDRESS)
2. unix:path= instead of unix:// because dbus-fast wants it in this format: https://github.com/Bluetooth-Devices/dbus-fast/blob/fb016aa33f848dd7542c6faaae281a5a225298f3/src/dbus_fast/_private/address.py#L52 — it's possible other implementations support the other format.

Either way, thanks for the pointer!

[PureTryOut]

Is that something that can be set by default then? I'm not personally using a container that has apt available, but will that conflict if apt is available?

[89luca89]

If you want it to be the default, you can add it to env at creation time distrobox create --additional-flags "--env DBUS_SESSION_BUS_ADDRES=unix:///run/host/var/run/dbus/system_bus_socket" ...

[PureTryOut]

I meant by default here in the repo 😉

[89luca89]

Can you point me to some example of apps that would benefit from this? So I can do some testing 👍

I'm a bit hesitant on this, as adding this by default would hamper the initful containers

[PureTryOut]

Well for one every Flutter app using Canonical's dbus package that wants to access a system service, e.g. getting a device geolocation. In my case that's a company thing I can't share, but I'm sure there are some out there.

But if it breaks other stuff then that's a good enough reason for me to not do it, don't worry 😉

[89luca89]

We van document this in the useful_tips so that the use case can be covered maybe

[PureTryOut]

Note that /run/host/var/run/dbus/system_bus_socket is not actually available in the container. Not sure why as the rest of the host system is 🤷

I don't currently see a way to access the system dbus socket from within the container.

[89luca89]

Note that /run/host/var/run/dbus/system_bus_socket is not actually available in the container. Not sure why as the rest of the host system is 🤷

I don't currently see a way to access the system dbus socket from within the container.

The correct path I think is /run/host/run/dbus/system_bus_socket
I've seen that most distros link /var/run (and subsequently /run/host/var/run) to /run which in the container will resolve to the container's /run

So you can set DBUS_SESSION_BUS_ADDRES=unix:///run/host/run/dbus/system_bus_socket"

As said previously this cannot be added by default, as it will break initful containers (which is probably the use case for you also) and it will make apt act strange as shown in #246

[gianfelicevincenzo]

I was about to open a ticket when I read this. For now, I think I've solved it by creating a symbolic link to /run/dbus.

mkdir /run/dbus
ln -s /run/host/run/dbus/system_bus_socket /run/dbus/system_bus_socket

the method with DBUS_SESSION_BUS_ADDRESS=unix:///run/host/run/dbus/system_bus_socket does not work as it is not the correct location of the socket

[archerallstars]

This is the real answer to fix the Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory issue.

Creating the container with --additional-flags "--env DBUS_SESSION_BUS_ADDRESS=unix:path=/run/host/run/dbus/system_bus_socket" doesn't solve the issue for me.

I use Arch's docker image, by the way.

[PureTryOut]

That works! Thanks that's an awesome solution due to being permanent, no messing around with environment variables any more.

[ivucica]

Since this was one of the top results for query "container expose dbus system socket", let me chime in:

DBUS_SESSION_BUS_ADDRESS=unix:///run/host/run/dbus/system_bus_socket should likely¹ be DBUS_SESSION_BUS_ADDRESS=unix:path=/run/host/run/dbus/system_bus_socket.

This is more obvious if you do env | grep ^DBUS_SESSION_BUS_ADDRESS= on a working machine and observe the value, or observe the error when doing it the right way (dbus-send --address unix:path=/run/host/run/dbus/system_bus_socket or dbus-monitor --address unix:path=/run/host/run/dbus/system_bus_socket; those will actively complain about a lack of = if you use your syntax).

Now, of course, you will have a separate problem if your application wants to access the session bus instead of a system bus; on the host machine, the former will be somewhere in your homedir, not in systemwide /run / /var/run.

Footnotes

1. I have not validated if envvar tolerates the different syntax, but passing that syntax directly into --address flag of the core dbus utilities seems not to work. But using the environment variable used to define the session bus in order to access the system bus seems... odd. ↩

[89luca89]

Converted to discussion to keep it for future reference