[pulseaudio-discuss] Pulse audio's UNIX sockets and other questions about pulse and containers

[Tanu Kaskinen]

On Fri, 2017-02-10 at 19:08 +0100, Timothy Hobbs wrote:
> Hello,
> 
> I'm trying to discover the best way to share pulse audio between linux 
> containers. I have found a great deal of answers to this problem online. 
> Some of them involve sharing UNIX sockets, while others suggest 
> connecting via localhost using port tunneling or otherwise. I want to 
> use UNIX sockets and take advantage of POSIX's existing and excelent 
> naming, namespacing, and security mechanisms. I guess that shouldn't be 
> a problem, because pulse audio seems to support unix sockets. But I'm 
> having trouble understanding their layout or finding any documentation 
> on what data gets transfered via which mechanism and which APIs are 
> exposed via what protocol. So far I've found that there are unix sockets 
> in the following places:
> 
> - $HOME/.config/pulse/<gobldygook>-runtime
> 
> This is just a link to:
> 
> - /tmp/<gobldygook>-pulse/
> 
> But how does this differ from the one in run?
> 
> - /run/user/$UID/pulse/

Those two directories serve the exact same purpose.
/run/user/$UID/pulse is used when $XDG_RUNTIME_DIR is set, otherwise
pulseaudio creates the directory under /tmp.

> I seem to recall that there is also system wide socket, not associated 
> with any single user of the system. However, I do not remember its location.

That socket only exists when pulseaudio runs in the system wide mode
(i.e. it doesn't exist by default). The location is
"${localstatedir}/run/pulse/native" (I think that usually gets expanded
to /var/run/pulse/native).

> There is also discussion of PULSE_AUDIO_COOKIE. Is this really needed 
> when connecting to UNIX sockets? Are these sockets stand alone or does 
> pulse audio also communicate over dbus or x11 or something?

In the most common setups the cookie is not used with unix sockets. In
the per-user setup the user who runs pulseaudio is always allowed to
connect, and other users aren't expected to connect anyway. In the
system-wide setup access is controlled via group membership (users not
in the "pulse-access" group are denied access).

It's possible to use the cookie authorization with unix sockets, but I
can't think of any situation where that would be the best solution.

Pulseaudio uses dbus and x11, but not for anything really important, so
I expect that you can live without them.

> For my usecase, the localhost option is a non-starter. It involves 
> configuring networking in the container to allow for the tunneling of 
> some ports which seems fiddly and like a can of worms from a security 
> perspective. Even if I weren't useing containers, I don't like the idea 
> of accessing services through localhost. Numbered ports with no human 
> readable names? No namespacing between users? Security from the outside 
> world ensured through conventions, manual checks, and hacks? Good greif!
> 
> If you have other suggestions that don't involve networking, I'd be 
> happy to hear them. I do hope, though, that if there isn't one already, 
> we'll be able to create a page as informative as this one <xpra 
> container page> for using pulse audio with containers.

Sharing the native protocol unix socket should work. If you want to use
a non-standard socket location, pass the "socket" option to module-
native-protocol-unix and set "default-server = /path/to/socket" in
client.conf so that clients find the socket.

I'd guess a container trying to connect to a socket from a different
container will get blocked by default. If you put the socket in a place
that only trusted users can access, then you can safely pass the auth-
anonymous option to module-native-protocol-unix.

-- 
Tanu

https://www.patreon.com/tanuk