please add getsockopt to pulseaudio interface

[Bruno Nova]

Pulseaudio, or at least the "paplay" command, doesn't work without the network plug/interface.

Running that command inside a snap with the pulseaudio interface prints something like this in the journal:

Jul 01 21:02:08 bruno-laptop audit[27684]: SECCOMP auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=27684 comm="paplay" exe="/snap/tetris-em-racket/x1/usr/bin/pacat" sig=31 arch=c000003e syscall=55 compat=0 ip=0x7fa4b5b3892a code=0x0
Jul 01 21:02:08 bruno-laptop kernel: audit: type=1326 audit(1467403328.239:86): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=27684 comm="paplay" exe="/snap/tetris-em-racket/x1/usr/bin/pacat" sig=31 arch=c000003e syscall=55 compat=0 ip=0x7fa4b5b3892a code=0x0

Note: snapd 2.0.10 or later (which is in xenial-proposed right now) is required to even get this far.
The snap also needs to bundle "pulseaudio-utils" for it to work.

[ORIGINAL DESCRIPTION]
I was packaging a small Racket/Scheme game.
Sound playback doesn't work, even with the pulseaudio interface.

According to https://docs.racket-lang.org/gui/Windowing_Functions.html#%28def._%28%28lib._mred%2Fmain..rkt%29._play-sound%29%29 , Racket uses the "aplay" command (or others) to play sound, but it isn't available inside the snap.
I tried bundling the alsa-utils package, but it throws an error when trying to play a sound.

Maybe the pulseaudio interface should grant access to these commands and everything else that is required?

[Sebastien Bacher (seb128)]

that could be the same than bug #1594318

[Bruno Nova (brunonova)]

The aplay, paplay, etc. commands don't exist inside the snap.
I guess the ubuntu-core snap doesn't include them.

However, I tried to apply the workaround from bug #1594318 and add a wrapper script to the snap called "aplay" that would run "paplay", but there's still no sound.
It complains that "connection refused", and the journal informs that AppArmor is denying access to "/etc/machine-id".
Giving access to that file in the AppArmor profile solves the "connection refused" error, but there's still no sound.

[Sebastien Bacher (seb128)]

using paplay works fine here on snapd 2.0.9, could you share you snapcraft.yaml/launcher script?
Note that snapd 2.0.10 from yesterday allows access to the machine-id file and fixes bug #1594318 so it would be worth trying if that resolves your issues

[Bruno Nova (brunonova)]

Thanks! I'll wait for 2.0.10 to reach Xenial, then I'll try it.

[Sebastien Bacher (seb128)]

it's in xenial-proposed if you want to test from there

[Bruno Nova (brunonova)]

OK, I found what the problem is:
For pulseaudio to work (or at least paplay), the network plug/interface also needs to be added.
Snapd 2.0.10+ is also needed.

Without the network plug, running paplay prints these messages to the journal:

Jul 01 21:02:08 bruno-laptop audit[27684]: SECCOMP auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=27684 comm="paplay" exe="/snap/tetris-em-racket/x1/usr/bin/pacat" sig=31 arch=c000003e syscall=55 compat=0 ip=0x7fa4b5b3892a code=0x0
Jul 01 21:02:08 bruno-laptop kernel: audit: type=1326 audit(1467403328.239:86): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=27684 comm="paplay" exe="/snap/tetris-em-racket/x1/usr/bin/pacat" sig=31 arch=c000003e syscall=55 compat=0 ip=0x7fa4b5b3892a code=0x0

Adding the network plug fixes this.

So, this needs to be investigated.
The pulseaudio interface also needs some kind of local network access. But giving it full network and Internet access is not a great idea.

I'll edit the bug description accordingly.

---

"aplay" still doesn't work.
It throws this error:

ALSA lib conf.c:3750:(snd_config_update_r) Cannot access file /usr/share/alsa/alsa.conf
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default
aplay: main:722: audio open error: No such file or directory

I'll report this in another bug.

[Zygmunt Krynicki (zyga)]

So syscall 55 is "getsockopt" which is not added by the pulseaudio plug connection. The system call is also not present in neither apparmor nor seccomp templates.

[Zygmunt Krynicki (zyga)]

Inspecting pulseaudio source code I see only the following references to getsockopt:

zyga@x200t:/tmp/pulseaudio-8.0$ grep -R getsockopt .
./src/pulsecore/poll-win32.c: /* Under Wine, it seems that getsockopt returns 0 for pipes too.
./src/pulsecore/socket-client.c: if (getsockopt(c->fd, SOL_SOCKET, SO_ERROR, (void*)&error, &lerror) < 0) {
./src/pulsecore/socket-client.c: pa_log("getsockopt(): %s", pa_cstrerror(errno));
./src/pulsecore/socket-client.c: pa_log("getsockopt() returned invalid size.");
./src/modules/module-esound-sink.c: if (getsockopt(u->fd, SOL_SOCKET, SO_SNDBUF, (void *) &so_sndbuf, &sl) < 0)
./src/modules/module-esound-sink.c: pa_log_warn("getsockopt(SO_SNDBUF) failed: %s", pa_cstrerror(errno));
./src/modules/raop/module-raop-sink.c: if (getsockopt(u->fd, SOL_SOCKET, SO_SNDBUF, &so_sndbuf, &sl) < 0)
./src/modules/raop/module-raop-sink.c: pa_log_warn("getsockopt(SO_SNDBUF) failed: %s", pa_cstrerror(errno));

We can ignore the win32 code and then we are left with two modules and a core file:

- the esound module is likely unused here
- the raop module is for AirPlay support (I guess not being used here)

This leaves us with ./src/pulsecore/socket-client.c, reading the code there it is getsockopt is only called from do_call() which is (via a bunch of static helpers) called from nearly every pa_socket_client_new_{ipv4,ipv6,...} functions.

I'm not familiar with pulseaudio architecture to know if this is something that simply always required or only in certain configurations.

The interesting aspect is that the actual call looks like this:

getsockopt(c->fd, SOL_SOCKET, SO_ERROR, (void*)&error, &lerror)

Looking at snap-confine I don't see any support for getsockopt argument filtering that would allow us to let pulseaudio always call this particular flavor of getsockopt.

[Jamie Strandboge (jdstrand)]

The fix is simply to add 'getsockopt' to the seccomp connected plug policy and don't bother with seccomp arg filtering (I don't think that is needed).

[Bruno Nova (brunonova)]

This fix is already in Xenial, right?

It seems syscall 55 (getsockopt) isn't the only syscall needed for paplay/pacat to work without the network interface.
I now see in the logs a new denial for syscall 46 (sendmsg, according to https://filippo.io/linux-syscall-table/).

I've uploaded a snap that displays this issue when you disconnect the "network" interface.
You can use it for testing. The snap is tetris-in-racket.
Sound playback is currently not working due to a missing library, but it should be fixed when the new version is build and uploaded by Launchpad, which should happen in a few minute, I hope.

[Jamie Strandboge (jdstrand)]

This was fixed in 2.12 and is available in xenial-updates.