Hello, thank you for the detailed response. I'm trying to test this now,
but without success. I have given my container access to the sockets,
the pulse audio config directory in `~/.config/pulse`. I have given it
the same UID and username as my normal user. I have given it the same
`/etc/machine-id`. And all I get when I try to interact with pulse audio
in my container is:
timothy at dcd7aa1c2b23de93306d:~/Downloads$ paplay 0916.ogg
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
You mention that I should set auth-anonymous, so I added that to
/etc/default.pa and restarted my computer. No luck. One thing I did
notice was that used=-1 when I type `info` in pacmd on the host machine:
index: 8
name: <module-native-protocol-unix>
argument: <auth-anonymous=yes>
used: -1
load once: no
properties:
module.author = "Lennart Poettering"
module.description = "Native protocol (UNIX sockets)"
module.version = "5.0"
I'm not really sure how much I should be investing in the auth-anonymous
approach. I'd like this to work on computers that I don't control, and
I'm not sure to what extent it is acceptable for me to be reconfiguring
pulse under other people's feet.
Regards and thanks for your help so far,
Timothy Hobbs
On 02/16/2017 12:53 PM, Tanu Kaskinen wrote:
> 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.
>
