1384611 - Make AEC logging work in sandbox

Status: RESOLVED DUPLICATE of bug 1404982

(Core :: WebRTC: Audio/Video, enhancement, P3)

Description

[Dan Minor [:dminor]]

AEC logging does not work when sandboxing is enabled.

From jesup in irc:

AEC logs need to open files, which you can't do in content with a sandbox.  To solve this we need to remote the save, OR get the sandbox to allow us to write to a (single) temp location, which I think they were talking about doing (or did?) -- if so, save there.  Ask jimm in #boxing.

Comment 1

[Alex Chronopoulos [:achronop]]

The temp directory is given by the key NS_APP_CONTENT_PROCESS_TEMP_DIR. It may not work in Linux but /tmp directory is available there. 

More in irc logs from #boxing channel:

6:25 PM 
<achronop> the bug is unassigned and without priority, what is the time frame for this?
6:33 PM 
<gcp> I don't think anyone is even planning to work on it short term?
6:37 PM 
<achronop> can we get a temporary solution, like to allow a specific filepatch or anything you feel comfortable with
6:39 PM 
<gcp> there may be per-content process temp dirs that are writable
6:40 PM 
<gcp> (in linux, we still allow /tmp)
6:40 PM 
<gcp> which we use for printing?
6:41 PM 
<gcp> not sure on macos and win state of those
6:41 PM 
<jimm> achronop: we have a few logging related bugs under bug 1383253
6:41 PM 
<firebot> https://bugzil.la/1383253 — NEW, [e-mail] — [meta] Logging issues with the process sandbox
6:42 PM 
<achronop> I am testing now on mac and logs are are stored in /var/folders/3s/2gqp42nd6w30k7wfc59xbv2m0000gn/T
6:42 PM 
<jimm> if something there fit please post str or a description of the issue and a way to test. if no open bugs fit, please file a new bug with str and we'll take a look..
6:43 PM 
<gcp> https://bugzilla.mozilla.org/show_bug.cgi?id=1344776
6:43 PM 
<firebot> Bug 1344776 — NEW, [e-mail] — MOZ_LOG doesn't work for child processes because of sandboxing, other OS but Windows
6:44 PM 
<achronop> if /tmp is allowed on mac I could see if we can change the path
6:44 PM 
<jimm> gcp: added that to the tracker
6:44 PM 
<gcp> "The key is NS_APP_CONTENT_PROCESS_TEMP_DIR."
6:44 PM → tracy joined ([e-mail])
6:45 PM 
<gcp> except on linux
6:45 PM 
<gcp> which could be considered a bug, maybe
6:46 PM 
<haik> achronop: is this logging that you'd like to be able to use in release and turn on dynamically?
6:47 PM 
<gcp> haik: yes, they are :P
6:47 PM 
<haik> I think we talked a bit about this in SF and (not sure) but I think we were wondering if it made more sense for another team to work on this
6:47 PM 
<gcp> haik: or rather, they *were*
6:47 PM ⇐ LCPolan quit ([e-mail]) Quit: My MacBook Air has gone to sleep. ZZZzzz…
6:47 PM 
<haik> gcp: ok :)

Comment 2

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

This is a P1 bug without an assignee. 

P1 are bugs which are being worked on for the current release cycle/iteration/sprint. 

If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Dan - this is an important debugging facility, without which it's very hard to diagnose or attack audio echo issues (and some other audio issues, since this lets us capture audio in and out of the browser).  p2/25 is really too low for this -- though I realize it's blocked by external issues (unless we hand-roll something to open the files and forward all the data over IPC to be written -- ugh).

Comment 4

[Dan Minor [:dminor]]

(In reply to Randell Jesup [:jesup] from comment #3)
> Dan - this is an important debugging facility, without which it's very hard
> to diagnose or attack audio echo issues (and some other audio issues, since
> this lets us capture audio in and out of the browser).  p2/25 is really too
> low for this -- though I realize it's blocked by external issues (unless we
> hand-roll something to open the files and forward all the data over IPC to
> be written -- ugh).

I moved it because we are apparently no longer allowed to have unassigned P1s and it seemed like we would be waiting for some fixes on the sandboxing side.

Comment 5

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 6

[Dan Minor [:dminor]]

I think Paul's plan over in Bug 1404982 is probably the best way ahead here.