58 bytes, text/x-review-board-request
Spawned from bug 1247056 comment 167. drJeckyll found out that compiling Firefox on Linux with --enable-alsa and --disable-pulseaudio results in no sound being played anymore in bug 1247056 comment 166. I see that the content sandbox recent tightening  is denying access to some files when cubeb is trying to start: > Sandbox: SandboxBroker: denied op=0 rflags=2000002 perms=3 path=/dev/snd/controlC0 for pid=37387 error="No such file or directory" > Sandbox: SandboxBroker: denied op=0 rflags=2000002 perms=3 path=/dev/snd/controlC0 for pid=37387 error="No such file or directory" > [Child 37387] WARNING: AudioStream::OpenCubeb() 7f8044a08700 failed to init cubeb: file dom/media/AudioStream.cpp, line 377 To confirm this, drJeckyll and I did the following: - In about:support, in the "Graphics" section, the "Audio Backend" showed "alsa" (this shows that we at least tried to use ALSA.) - In about:config, "security.sandbox.content.level" is at 2 by default; changed it to 1, restarted Firefox, and sound was working again. Interestingly, when I tried to enable pulseaudio only (the default now), I also got sandbox issues: > Sandbox: SandboxBroker: denied op=6 rflags=700 perms=3 path=/run/user/1000/pulse for pid=64481 error="Permission denied" > Failed to create secure directory (/run/user/1000/pulse): Permission denied > [Child 64481] WARNING: Could not get a cubeb context.: 'rv == CUBEB_OK', file dom/media/CubebUtils.cpp, line 216 > [Child 64481] WARNING: Can't get cubeb context!: file dom/media/AudioStream.cpp, line 352 But I haven't noticed any new bug about this (which I would have expected if sound stopped working altogether on Linux!), so maybe it's just something wrong on my side for this one.  https://groups.google.com/d/msg/mozilla.dev.platform/V-5G9dWJEXo/S9qxkg9EAgAJ
Do you know the exact distribution/version/platform? We have a number of ways of dealing with the ALSA issue, but I want to understand why PulseAudio is failing there (and working elsewhere).
(In reply to Gian-Carlo Pascutto [:gcp] from comment #1) > Do you know the exact distribution/version/platform? > > We have a number of ways of dealing with the ALSA issue, but I want to > understand why PulseAudio is failing there (and working elsewhere). Second sentence in comment 0: "compiling Firefox on Linux with --enable-alsa and --disable-pulseaudio" which also means whatever sandbox exception is added can be build-time conditional.
Yes, but that doesn't answer the question at all. I need to find out why PulseAudio breaks as well. It works on Ubuntu 16.04 on amd64, so what is reporter using?
You probably already had the pulseaudio daemon running, while gerald probably didn't, triggering code to launch it.
Yes, that's likely, but IIRC we did tweaks to encourage to start it up in the parent.
I'm running Ubuntu 16.04 LTS 64-bit in a VM. I had the pulseaudio service disabled, but if you compile FF with --disable-pulseaudio it shouldn't matter if it's installed. And I've got the following alsa packages installed: - alsa-base 1.0.25+dfsg-0ubuntu5 all - alsa-utils 1.1.0-0ubuntu5 amd64 Let me know if you need more info. (And how to get it, I'm only a Linux amateur!)
(In reply to Gian-Carlo Pascutto [:gcp] from comment #5) > Yes, that's likely, but IIRC we did tweaks to encourage to start it up in > the parent. See this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1259508 Understanding why PA fails to initialize despite this may reveal more about ALSA (rather than simply blowing holes into the sandbox for it).
Can we now return to --enable-alsa issue, because it is what span this bug? I use Gentoo Linux, and don't have pulseaudio installed.
(In reply to drJeckyll from comment #8) > Can we now return to --enable-alsa issue, because it is what span this bug? As already explained in the previous comment, the issue affecting PA is potentially the same as the one affecting ALSA, so it's important to understand what is actually going on. I did a test and on my system ALSA-only mode just works without any workarounds. I'll check in a VM without a full DE whether I can reproduce the issue.
With patch from comment #9 (https://reviewboard.mozilla.org/r/84930/diff/1#index_header), and with security.sandbox.content.level set to 2 (default) I have sound again.
Julian, can you see what's up with the PA-hasn't-started-yet use case? If fixing that doesn't fix ALSA as a side effect, I'll just land the patch in here.
Assignee: nobody → julian.r.hector
:gcp I done some testing on a VM in a similar environment as described in Comment 6. I have disabled pulseaudio by running > pulseaudio --kill And setting autospawn=no in $HOME/.config/pulse/client.conf. Even though we have the early initialization of the cubeb context, but for the pulseaudio it is the case that cubeb_init (and therefore pulse_init) fails when the pulseaudio daemon is not running. So the singleton instance of the context does not get initialized and the initialization code is triggered again once seccomp is enabled as soon as actual audio replay is requested. This problem is unrelated to the ALSA problem here, fixing the pulseaudio issue would involve making sure the pulseaudio daemon is started before initializing cubeb.
Comment on attachment 8799813 [details] Bug 1309098 - Add ALSA devices to filesystem policy whitelist. https://reviewboard.mozilla.org/r/84930/#review97416 ::: security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp:148 (Diff revision 2) > - // Bug 1312678: radeonsi/Intel with DRI when using WebGL > + // Bug 1312678: radeonsi/Intel with DRI when using WebGL > policy->AddDir(rdwr, "/dev/dri"); > > +#ifdef MOZ_ALSA > + // Bug 1309098: ALSA support > + policy->AddDir(rdwr, "/dev/snd"); Wasn't the point that pulseaudio also needs alsa, making this not a MOZ_ALSA-only thing?
Attachment #8799813 - Flags: review?(mh+mozilla)
(In reply to Mike Hommey [:glandium] from comment #15) > Wasn't the point that pulseaudio also needs alsa, making this not a > MOZ_ALSA-only thing? No. PulseAudio seems to do whatever initialization is needed on these "control" device nodes when it itself starts up, which is before our sandbox activates. ALSA can't do this because it's not persistent in the way PA is.
Comment on attachment 8799813 [details] Bug 1309098 - Add ALSA devices to filesystem policy whitelist. https://reviewboard.mozilla.org/r/84930/#review97480
Attachment #8799813 - Flags: review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/5ae2260e20e7 Add ALSA devices to filesystem policy whitelist. r=glandium
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox53: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
You need to log in before you can comment on or make changes to this bug.