SandboxBroker blocks /dev/snd/controlC0, which prevents using ALSA on Linux

RESOLVED FIXED in Firefox 53

Status

()

Core
Security: Process Sandboxing
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: gerald, Assigned: tedd)

Tracking

(Blocks: 1 bug)

49 Branch
mozilla53
All
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox53 fixed)

Details

(Whiteboard: sblc2)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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 [1] 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.


[1] https://groups.google.com/d/msg/mozilla.dev.platform/V-5G9dWJEXo/S9qxkg9EAgAJ
Blocks: 1289718
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?
Depends on: 1104619
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.
(Reporter)

Comment 6

2 years ago
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).

Comment 8

2 years ago
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.
Whiteboard: sblc2
Comment hidden (mozreview-request)
(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.

Comment 11

2 years ago
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
(Assignee)

Comment 13

2 years ago
: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 hidden (mozreview-request)

Comment 15

2 years ago
mozreview-review
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 17

2 years ago
mozreview-review
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+

Comment 18

2 years ago
Pushed by gpascutto@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5ae2260e20e7
Add ALSA devices to filesystem policy whitelist. r=glandium

Comment 19

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/5ae2260e20e7
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox53: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53

Updated

a year ago
Blocks: 1104619
No longer depends on: 1104619
You need to log in before you can comment on or make changes to this bug.