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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss