Closed Bug 1335329 Opened 3 years ago Closed 3 years ago
Audio breaks when sandbox broker returns EACCES instead of EEXIST for existing non-writable directory
32.19 KB, image/jpeg
3.17 KB, text/plain
4.07 KB, text/plain
42.62 KB, text/plain
59 bytes, text/x-review-board-request
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170130110114 Steps to reproduce: Navigate to: https://meet.jit.si/TestFirefox. I expect that Firefox asks me if I agree to share my microphone and camera, but that does not happen. Linux dmesg for my headset: [351618.448215] usb 1-6: USB disconnect, device number 10 [351621.221795] usb 1-6: new full-speed USB device number 11 using xhci_hcd [351621.366882] usb 1-6: New USB device found, idVendor=1395, idProduct=0025 [351621.366894] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [351621.366902] usb 1-6: Product: Sennheiser USB headset [351621.366909] usb 1-6: Manufacturer: Sennheiser Communications [351621.382287] input: Sennheiser Communications Sennheiser USB headset as /devices/pci0000:00/0000:00:14.0/usb1/1-6/1-6:1.3/0003:1395:0025.0009/input/input29 [351621.442235] hid-generic 0003:1395:0025.0009: input,hidraw4: USB HID v1.00 Device [Sennheiser Communications Sennheiser USB headset] on usb-0000:00:14.0-6/input3 I use pulseaudio, and "about:support" reports that "Backend audio" is set to "pulse". I tried to create a fresh new Firefox profile but that did not solve the problem. I get the same exact behavior. I tried with the Firefox version (Firefox/Iceweasel ESR 45.7.0) shipped with my Linux distribution (Debian Sid), and it worked there. So the issue is in Firefox Nightly for me. Actual results: Firefox does not ask me if I agree to share my microphone and camera. So I end up with an error message from the website: "There was an error connecting to your microphone. Microphone was not found." Expected results: Firefox should ask me if I want to share my microphone and camera.
Can you please capture some logs with the latest Nightly version of firefox. In order to do that download Nightly. export the following env var before run it, and run it. export MOZ_LOG=timestamp,cubeb:4,GetUserMedia:4 ./path/to/nightly/firefox Logs will appear on screen (stdout), please copy and paste them to a file and attach them here.
Logs file now attached to the bug.
Either we are missing some logs at the end or the audio backend does not try to enumerate your devices which is not good. Could you please capture the same logs from the following test page: https://mozilla.github.io/webrtc-landing/gum_test.html using the Audio option.
New logs file attached. I get "Failed to create secure directory (/run/user/1000/pulse): Permission denied" in the logs each time I click on the "Audio" button on https://mozilla.github.io/webrtc-landing/gum_test.html. And the Audio page displays "NotFoundError: The object can not be found here."
Thanks for the fast response. Can you please check if setting media.navigator.audio.full_duplex = false in about:config fixes the problem, my expectation is not to fixing it.
No, same problem with media.navigator.audio.full_duplex = false.
Well, I am expecting that the sound output or input does not work at all in that version of FF, meaning that you cannot hear any music or video file. I found that bug which is close to your symptoms (a little old) from Ubuntu https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1197395 Can you check if anything there can fix your problem. Otherwise please gather some data about your PulseAudio version and configuration in order to contact pulse's developers.
Audio actually works in Firefox. With both the built-in Audio Analog Stereo and the Senheiser USB headset Analog Stereo.
I'm able to reproduce the issue. I get 3 permission dialog boxes about sharing mic, then camera then mic again. After allowing the mic a 2nd time (why?), I get the error about sharing the camera. So only audio is available. The funny thing is it's only broken with e10s enabled! Regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=935e36fde31c6ecd8321beb29d896e42a70aecd0&tochange=126348e718d03dec640b30b5def70fce8aa71527
Status: UNCONFIRMED → NEW
Component: Audio/Video: Recording → WebRTC
Ever confirmed: true
Version: 54 Branch → 53 Branch
Loic - that sounds like a different bug than what the reporter hit. What camera do you have? Can you run Nightly with MOZ_LOG=GetUserMedia:4,MediaManager:5,webrtc_trace:5 WEBRTC_TRACE_FILE=nspr and attach the log to a new bug? Also please run the same log settings with e10s off and upload. Thanks!
Flags: needinfo?(rjesup) → needinfo?(epinal99-bugzilla2)
Eric: did you restart the browser after switching the full_duplex config? What happens on that same system using Chrome? Alex - perhaps whatever is blocking input in cubeb full-duplex is also blocking it in the non-full-duplex code in the webrtc.org audio capture code.
> Eric: did you restart the browser after switching the full_duplex config? I just tried, and it did not work. > What happens on that same system using Chrome? Chromium works fine. And Firefox/Iceweasel ESR 45.7.0 shipped with Debian Sid works fine too!
(In reply to Randell Jesup [:jesup] from comment #12) > Loic - that sounds like a different bug than what the reporter hit. > > What camera do you have? Can you run Nightly with > MOZ_LOG=GetUserMedia:4,MediaManager:5,webrtc_trace:5 WEBRTC_TRACE_FILE=nspr > and attach the log to a new bug? Also please run the same log settings with > e10s off and upload. Thanks! See bug 1336073. (I fail to have a log with e10s enabled, I guess the issue is here)
I just tried https://test.webrtc.org/, and I get this error for the Microphone: Audio capture [ FAILED ] Failed to get access to local media due to error: NotFoundError The Camera is fine. In Chromium both the Microphone and the Camera are okay.
Can you please test 2 things for me: Test 1: change the value of pref security.sandbox.content.level in about:config to 0 and retry Test 2: open a new Non-e10s window and retry
> Test 1: change the value of pref security.sandbox.content.level in about:config to 0 and retry Yep, that test passes!
gcp: can you please take a look, the sandbox seems to create a problem in PulseAudio record operation.
> Test 2: open a new Non-e10s window and retry That seems to work too. (without security.sandbox.content.level set to 0 in about:config)
Is it possible to set MOZ_SANDBOX_LOGGING=1 and launch Firefox, then attach a log to this bug? This is Debian Sid right? Any particular desktop enviroment? (GNOME/KDE/MATE/XFCE/...)?
Whiteboard: [webcompat] → sb?
Also this needs to be done in e10s mode. The reason why it works with e10s off is that you have no sandbox without multiprocess.
> Is it possible to set MOZ_SANDBOX_LOGGING=1 and launch Firefox, then attach a log to this bug? I already attached logs to this bug. Do you need more? > This is Debian Sid right? Any particular desktop enviroment? (GNOME/KDE/MATE/XFCE/...)? i3 window manager
(In reply to eric.lemoine from comment #23) > > Is it possible to set MOZ_SANDBOX_LOGGING=1 and launch Firefox, then attach a log to this bug? > > I already attached logs to this bug. Do you need more? Yes, if you set that enviroment variable you'll get more verbose output which should highlight the exact problem.
Do you also want MOZ_LOG to be set to "timestamp,cubeb:4,GetUserMedia:4" as requested initially?
Firefox Nightly logs 3
Attachment #8832920 - Attachment description: firefox-nightly-logs-3.txt → Firefox Nightly logs 3
New logs file attached: firefox-nightly-logs-3.txt.
I ran into this using fvwm on Ubuntu; bug 1321134 has some notes, and bug 1321134 comment #2 explains why it's not reproducible using the normal Ubuntu desktop environment. A possible fix that doesn't increase the sandboxed process's actual permissions (and might help with other issues in the future): modify the broker so that, if mkdir is called on a path that doesn't have the create bit in the broker policy but does have the read bit, then lstat the path and return EEXIST if it exists. (This could also be done on the client side.)
See Also: → 1321134
That's a discussion I had in #pulseaudio about it in case it helps: <achronop> I use the api to record and playback in linux, recently added a sandbox in the application which restrict the access to the file system for non authorized processes <achronop> when activate the sandbox and try to record from mic I get: Failed to create secure directory (/run/user/1000/pulse): Permission denied <achronop> this does not happen on playback <Korigan> achronop, guess you have a problem with your pulse audio user, not allowed to rw through this output <achronop> can you please tell me at which point the pa_stream_connect_record (my guess) create a secure dir ? <achronop> Korigan: my user can rw, application's sandbox does not allow the app's processes to do non authorized rw <achronop> Korigan: well maybe sandbox restricts the pulse user as you said, I am not sure how sandbox works <Ford_Prefect> achronop: pong <Ford_Prefect> achronop: it's odd that playback works, tbh <achronop> Ford_Prefect: hi, sorry it must be late there <Ford_Prefect> achronop: no problem! <achronop> yeah, that makes me wonder too, I cannot tell why playback and not record <Ford_Prefect> achronop: so the XDG_RUNTIME_DIR is where we try to connect to the pulseaudio unix socket → friedrich joined (~friedrich@2a03:4000) <achronop> Ford_Prefect: what is this socket for? <Ford_Prefect> achronop: this is the socket on which you talk to the PA server, to set up the stream, query devices, everything except (usually) transferring audio data <Ford_Prefect> audio data happens over SHM, unless you've disabled that <achronop> then playback should use the same socket, right? <Ford_Prefect> Yup <Ford_Prefect> It's very puzzling -- is the setup exactly the same for playback and capture? <Ford_Prefect> Could that error you're seeing be a red herring? <achronop> sandboxing in already on it, probably they have done something for playback and not for record <Ford_Prefect> Could it be that the runtime dir is open for playback, but closed off in the record case? <achronop> yeah they are similar the only difference is that they are two separated pa_streams <Ford_Prefect> So my first guess would be differences in the sandbox setup for playback and capture <Ford_Prefect> If that's definitely the same and you have a branch / testcase for me to try, I can do that (probably tomorrow, tho)
Summary: Firefox nightly does not ask me if meet.jit.si should be given access to my microphone → PulseAudio breaks when sandbox broker returns EACCES instead of EEXIST for existing non-writable directory
Component: WebRTC → Security: Process Sandboxing
Comment on attachment 8833043 [details] Bug 1335329 - Improve handling of mkdir() on preexisting directories in Linux sandbox file broker. https://reviewboard.mozilla.org/r/109276/#review111152
Attachment #8833043 - Flags: review?(gpascutto) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/53023771039e Improve handling of mkdir() on preexisting directories in Linux sandbox file broker. r=gcp
Please request Aurora approval on this when you get a chance.
Tracking 53/54+ for this regression that is now fixed.
(In reply to Ryan VanderMeulen [:RyanVM] from comment #35) > Please request Aurora approval on this when you get a chance. This doesn't do anything useful on Aurora until we actually turn on content process sandboxing, and we don't want to do that until we have a form of telemetry that's more polite than crashing, which is bug 1286865.
Talked about this with RyanVM out-of-band, and, on second thought: This also has no risk until/unless we flip the sandboxing pref, so we might as well uplift it sooner rather than later. But I'd like to give it a day or two on m-c, just in case it winds up being a net increase in breakage and needs to get backed out.
Comment on attachment 8833043 [details] Bug 1335329 - Improve handling of mkdir() on preexisting directories in Linux sandbox file broker. Approval Request Comment [Feature/Bug causing the regression]: Bug 1337162, which hasn't happened yet, but it's been suggested that I should request uplift on the known blockers ASAP. [User impact if declined]: Blocks bug 1337162, which is for letting a first draft of Linux content process sandboxing ride the trains. Specifically, this will break getUserMedia on some Linux systems *if* sandboxing rides the trains without this patch. [Is this code covered by automated tests?]: Yes; there are existing unit tests for the broker (which are run on all branches), and the patch adds regression tests for what it's fixing. [Has the fix been verified in Nightly?]: It's been on m-c for a few days. [Needs manual test from QE? If yes, steps to reproduce]: No; I've tested locally, since I have an affected system. [List of other uplifts needed for the feature/fix]: None. [Is the change risky?]: Small risk, but nonzero (with bug 1337162; zero risk without) [Why is the change risky/not risky?]: This changes the behavior inside the sandbox to be closer to the unsandboxed behavior, so if anything it should be more likely to remove yet-unknown bugs than add them, but there are no guarantees. [String changes made/needed]: None.
Attachment #8833043 - Flags: approval-mozilla-aurora?
Comment on attachment 8833043 [details] Bug 1335329 - Improve handling of mkdir() on preexisting directories in Linux sandbox file broker. Fix an issue related to pulseaudio in some linux system. Aurora53+.
Attachment #8833043 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.