Re: [pulseaudio-discuss] Pulse audio's UNIX sockets and other questions about pulse and containers
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@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:
argument:
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/-runtime
This is just a link to:
- /tmp/-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 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.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinf
Re: [pulseaudio-discuss] Pulse audio's UNIX sockets and other questions about pulse and containers
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/-runtime
>
> This is just a link to:
>
> - /tmp/-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 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
[pulseaudio-discuss] Pulse audio's UNIX sockets and other questions about pulse and containers
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/-runtime This is just a link to: - /tmp/-pulse/ But how does this differ from the one in run? - /run/user/$UID/pulse/ 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. 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? 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 container page> for using pulse audio with containers. Thanks in advance, Timothy Hobbs ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
