Invalid IP given to Pulseaudio

[hackel]

I found an issue with pulseaudio support. When it pulls the docker IP range to use from grepping the ip command, it gets "172.17.0.1/16", which it then uses to authorize pulseaudio. This results in the following error:
May 29 02:47:40 hermes pulseaudio[7973]: [pulseaudio] ipacl.c: Host part of ACL entry '172.17.0.1/16' is not zero!

The last number in the allowed IP mask needs to be 0. e.g.
pacmd load-module module-native-protocol-tcp port=35744 auth-ip-acl=172.17.0.0/16
This works correctly, however I did have to disable my firewall (ufw).

I'm running Ubuntu 17.04.

PS—I love this script! I was trying to do the same thing using LXD and not having much luck. This really makes it super easy.

[mviereck]

Thanks for your feedback!

I'm a bit surprised, as using docker IP range works fine here (debian 9 with pulseaudio 10.0). Can you tell me your version of pulseaudio? (pulseaudio --version)

I've just uploaded x11docker v3.5.3. Instead of using docker iP range for pulseaudio TCP module, the IP of the container is used now. This is more specific and thus more secure. (Before, simultaneous containers could have tried to access host pulseaudio, too, although not intended).

Another change: Before I had trouble after disabling the TCP module, that stopped pulseaudio on host at all for unknown reasons, so I decided not unload the TCP module. Now it seems to work, and the TCP module is disabled on container exit without having troubles on host.

Could you check if pulseaudio now works in container, and if it still works on host after terminating the container?

This works correctly, however I did have to disable my firewall (ufw).

i could try to share pulseaudio unix socket instead of connecting over tcp. That would avoid firewall problems and may be more secure than a TCP connection to possible vulnerable pulseaudio.

PS—I love this script! I was trying to do the same thing using LXD and not having much luck. This really makes it super easy.

Thank you! :-)

[hackel]

Hmm, I'm also using pulseaudio 10.0 (1:10.0-1ubuntu2). I wonder if the issue wasn't rather with differences in the ip command output? I've got iproute2 4.9.0-1ubuntu1, which appears to be the same as Debian, though.

The new change works great for me. Audio is working fine both in the container and after closing the container on the host.

The unix socket approach sounds intriguing. I believe that could slightly eliminate some latency as well (although this wasn't a problem). For now I just opened up everything on the docker0 interface, that seems fairly harmless.

[mviereck]

Hmm, I'm also using pulseaudio 10.0 (1:10.0-1ubuntu2). I wonder if the issue wasn't rather with differences in the ip command output? I've got iproute2 4.9.0-1ubuntu1, which appears to be the same as Debian, though.

Strange; same versions here, and also having IP 172.17.0.1/16 for docker interface. However, it works now. If someone still has problems with a deactivated pulseaudio on host, he will hopefully tell me.

The unix socket approach sounds intriguing.

I gave it a try, and it was quite easy. But it has a drawback.

I can get some pulseaudio environment variables with xprop -root and I get:

$ xprop -root | grep PULSE
PULSE_COOKIE(STRING) = "667cd4f792b44a2b161658bb272d97e446528d3e2ac166971c14225caee7810e170712a992e2a3b36b53f23029cf73243fbe109ed034a5b672fa17ef5df55795916781f0c8ea16b7e782692cba865d53c5fb2a4cca03a9ed14929691867760485913ffc681bdadc93757e572694f74c0c5a699391fb54010aa557b58a63ae2b7960ed42b9096751d060ff980c06ef565faaa458d0104756c0ba8649e0511f0db19ecb899693c69e5fbb3c46600079c3709fbb87d3d73f19a82dcd0a34b19a3e2586ac4448bb0756c422286b8d22780ae40f6b10d7cc5e93e6a48a8546c5db275696b23ec84da4373483625fa1337f3876f629b82f094e7995d4a85d869a0a6a0"
PULSE_SERVER(STRING) = "{2b453596804544d385d72d36f5482faf}unix:/run/user/1000/pulse/native"
PULSE_SESSION_ID(STRING) = "1"
PULSE_ID(STRING) = "1000@2b453596804544d385d72d36f5482faf/2474"

I can parse this and have to share the socket and to set PULSE_SERVER and PULSE_COOKIE

docker run 
         -v /run/user/1000/pulse/native:/tmp/pulseaudiosocket \
         -e PULSE_SERVER=unix:/tmp/pulseaudiosocket \
         -e PULSE_COOKIE="667cd4f792b44a2b161658bb272d97e446528d3e2ac166971c14225caee7810e170712a992e2a3b36b53f23029cf73243fbe109ed034a5b672fa17ef5df55795916781f0c8ea16b7e782692cba865d53c5fb2a4cca03a9ed14929691867760485913ffc681bdadc93757e572694f74c0c5a699391fb54010aa557b58a63ae2b7960ed42b9096751d060ff980c06ef565faaa458d0104756c0ba8649e0511f0db19ecb899693c69e5fbb3c46600079c3709fbb87d3d73f19a82dcd0a34b19a3e2586ac4448bb0756c422286b8d22780ae40f6b10d7cc5e93e6a48a8546c5db275696b23ec84da4373483625fa1337f3876f629b82f094e7995d4a85d869a0a6a0" \
         imagename imagecommand

The drawback: Although this setup works fine ootb with images based on debian with pulseaudio installed, it does not work with kdeneon (based on Ubuntu). I did no further tests, but I assume that all Ubuntu or all KDE based systems will fail due to some different default configuration of pulseaudio.
I get kdeneon to work if also sharing /dev/shm: -v /dev/shm:/dev/shm. But that is bad from a security point of view, as other applications may store files in /dev/shm and the container would get access to them.

I believe that could slightly eliminate some latency as well (although this wasn't a problem).

I think, only sharing the unix socket won't be a great different to a local tcp connection. Sharing /dev/shm would most probably make a significant difference for those needing quite low latency.
I could add a less secure second pulseaudio option for this, but won't do this unless someone tells me he needs it.

I also found this does not work if I choose a container user different from host user. That may be solvable, though.

For now I just opened up everything on the docker0 interface, that seems fairly harmless.

I wonder if I could somehow check whether the port is blocked or not in a general way. At least I could show a warning if x11docker finds the tcp connection blocked.