Open
Bug 1104619
(sb-audio)
Opened 10 years ago
Updated 10 months ago
[meta] Sandboxing improvements when audio playback & recording are remoted
Categories
(Core :: Security: Process Sandboxing, defect, P3)
Core
Security: Process Sandboxing
Tracking
()
NEW
People
(Reporter: gcp, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: meta)
No description provided.
Reporter | ||
Updated•10 years ago
|
Reporter | ||
Updated•10 years ago
|
Assignee: nobody → gpascutto
Reporter | ||
Comment 1•10 years ago
|
||
WIP is being done on this branch:
https://github.com/gcp/gecko-dev/tree/sandbox-av
https://github.com/gcp/gecko-dev/compare/sandbox-av
Updated•9 years ago
|
Component: Audio/Video → Audio/Video: MSG/cubeb/GMP
Updated•9 years ago
|
Component: Audio/Video: MediaStreamGraph → Audio/Video: cubeb
Updated•9 years ago
|
Rank: 20
Priority: -- → P2
Comment 2•9 years ago
|
||
Should this be tracked by sandboxing? It looks like this could fix Bug 1259283.
Whiteboard: sb?
Updated•9 years ago
|
Whiteboard: sb? → sblc1
Comment 3•8 years ago
|
||
Moving to sblc2 because this is currently not blocking enabling seccomp on nightly. However, it will allow us to revert the patch landed as part of Bug 1259508, once audio is remoted.
Whiteboard: sblc1 → sblc2
Comment 4•8 years ago
|
||
Discussed this with :gcp over irc, he is not currently working on it.
Assignee: gpascutto → julian.r.hector
Comment 5•8 years ago
|
||
We should have a look at how chromium does this before proceeding. Also don't hesitate to ask any question, this is full of gotchas.
This is the code on the host side (= Chrome process for us): https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/audio_input_renderer_host.cc?sq=package:chromium&rcl=1474529952&l=349
Flags: needinfo?(julian.r.hector)
Comment 6•8 years ago
|
||
Thank you very much.
So far my approach is to remote the cubeb API found in cubeb.h. But I am currently dealing with a threading issue since I created a sync protocol. It seems that the Send method is called from a thread it can't block on.
I probably have to do something similar to the LockAndDispatch [1] that :gcp did on PCameras, which makes this slightly more complicated.
[1] http://searchfox.org/mozilla-central/rev/8910ca900f826a9b714607fd23bfa1b37a191eca/dom/media/systemservices/CamerasChild.cpp#188
Flags: needinfo?(julian.r.hector)
Comment 7•8 years ago
|
||
Oh and this is my working branch:
https://github.com/jhector/gecko-dev/tree/bug-1104619-remote-audio
Updated•8 years ago
|
Assignee: julian.r.hector → nobody
Updated•8 years ago
|
Whiteboard: sblc2 → sblc3
Updated•8 years ago
|
Whiteboard: sblc3 → sblc3, sbmc3
Updated•8 years ago
|
Whiteboard: sblc3, sbmc3 → sblc5
Updated•7 years ago
|
Updated•7 years ago
|
Alias: sb-audio
Priority: P2 → P3
Updated•7 years ago
|
Component: Audio/Video: cubeb → Security: Process Sandboxing
Updated•7 years ago
|
Updated•7 years ago
|
Comment 8•7 years ago
|
||
Retitling this bug to match what its new purpose seems to be. The audio remoting discussed in previous comments seems to now be covered in bug 1362220.
Updated•6 years ago
|
Summary: Sandboxing improvements when audio playback & recording are remoted → [meta] Sandboxing improvements when audio playback & recording are remoted
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•