Note: running Kodi with access to host avahi to enable zeroconf

[synclpz]

That was freaking tough.

TL;DR

Still using --hostnet (next step would be to setup isolated network)

• -- -v /var/run/dbus/:/var/run/dbus/ -- (use host's system dbus-daemon, socket address is hardcoded in avahi-client at compile time)
• --privileged or --security-opt apparmor=unconfined (circumvent AppArmor docker profile)

Long story

First of all, Zeroconf just didn't work even if enabled in GUI/config. So did not AirPlay, obviously. The log was saying:

ERROR: CZeroconfAvahi::createClient() failed with -26
ERROR: CZeroconfAvahi::CZeroconfAvahi(): Could not create client

Quick googling got me to sources of Kodi at https://github.com/xbmc/xbmc/blob/b5a9c397662dbb1b0aa2281c06582ca2bf3538c0/xbmc/platform/linux/network/zeroconf/ZeroconfAvahi.cpp#L353 which used avahi-client library. So I resorted to look up error code in avahi's docs and sources, found it at https://github.com/lathiat/avahi/blob/e8a3dd0d480a754318e312e6fa66fea249808187/avahi-common/error.h#L59, then https://github.com/lathiat/avahi/blob/master/avahi-client/client.c said it is related to DBus.

As you wrote in Wiki https://github.com/mviereck/x11docker/wiki/How-to-connect-container-to-DBus-from-host I tried to user --dbus (no luck because no dbus package installed in container) and --hostdbus which didn't work also.

Manually mounting /run/user/1000/bus to container and setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus got me no further, still with error -26.

I checked with dbus-monitor --address unix:path=/run/user/1000/bus that DBus is available on the socket from host, but not available from container (according to Kodi logs), which seemed very strange.

So, the next option was try to use system dbus daemon through /var/run/dbus/system_bus_socket, I forwarded it with -- -v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket -e DBUS_SESSION_BUS_ADDRESS=unix:path=/var/run/dbus/system_bus_socket -- to Kodi, and got:

ERROR: CZeroconfAvahi::createClient() failed with -20
ERROR: CZeroconfAvahi::CZeroconfAvahi(): Could not create client

So, looked up -20 equals AVAHI_ERR_ACCESS_DENIED, which equals DBUS_ERROR_ACCESS_DENIED (ha-ha, obvious thought I),

srw-rw-rw- 1 root root 0 Aug  6 19:19 /var/run/dbus/system_bus_socket

But no.

I'll skip a couple of iterations of trying with session DBus (always got -26, whatever I had done), after which I occasionally forgot to set -e DBUS_SESSION_BUS_ADDRESS=unix:path=/var/run/dbus/system_bus_socket and then boom, -20. So this revealed the magic behind -26 with session DBus: avahi-client library (?) just does not respect env and always connects to /var/run/dbus/system_bus_socket. As I found out socket address is discovered by autoconf at compile time.

Anyway, no luck connecting to DBus from container (access denied), but dbus-monitor --system works fine on host's shell even without sudo. After going through DBus' docs about authentication and all that stuff around, reading /etc/dbus-1/system.d/avahi-dbus.conf on host, confirming there were no rules that could potentially deny access, I still could not develop any plan to make it work.

I missed an obvious step -- look through syslog, and journalctl did show me the problem:

audit: type=1107 audit(1596733279.028:33): pid=823 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="Hello" mask="send" name="org.freedesktop.DBus" pid=8046 label="docker-default" peer_label="unconfined"

AppArmor fenced all DBus request as docker runs with label="docker-default". So the trivial way was just disabling AppArmor on my container with --privileged. It did the trick and my Kodi is announced on local network.

Next steps

As --privileged is not the right way of doing things I plan to investigate how to create a special profile and use it with Kodi (or other avahi-enabled software).

Links

• Docker's guide: https://docs.docker.com/engine/security/apparmor/
• Someone who faced the same problem: https://github.com/edgexfoundry-holding/device-bluetooth-c#apparmor
• And did it right way: https://github.com/edgexfoundry-holding/device-bluetooth-c/pull/15/files

PS

The most intriguing and misleading thing was that another container with Spotifyd perfectly announced itself through DNS SD, actually that was because an instance of avahi appeared to be compiled into spotifyd and it also listened on udp/5353.

udp        0      0 0.0.0.0:5353            0.0.0.0:*                           11430/spotifyd
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           822/avahi-daemon: r

[synclpz]

I was not sure if an this issue is the right place to share this information, but at least it is ok to have a track of process.

[mviereck]

Thank you for this documentation! It is quite interesting.

As --privileged is not the right way of doing things I plan to investigate how to create a special profile and use it with Kodi (or other avahi-enabled software).

You can disable apparmor with docker run option --security-opt apparmor=unconfined. You could add this to the x11docker command between -- --

[synclpz]

--security-opt apparmor=unconfined

It does also work.

Nevertheless I plan to make a profile for AppArmor at least for educational purpose :)

[mviereck]

Closing due to inactivity. Thank you for sharing your investigation!

[mviereck]

I've made a note of this thread in x11docker wiki: https://github.com/mviereck/x11docker/wiki/How-to-connect-container-to-DBus-from-host