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
