Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 776648 - Pass needed fds to child process through fd remap after fork()
: Pass needed fds to child process through fd remap after fork()
Product: Core
Classification: Components
Component: IPC (show other bugs)
: Trunk
: ARM Gonk (Firefox OS)
: -- normal (vote)
: ---
Assigned To: Guillaume Destuynder [:kang] (NEEDINFO to ensure replies)
: Bill McCloskey (:billm)
Depends on:
Blocks: 746280
  Show dependency treegraph
Reported: 2012-07-23 12:31 PDT by Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
Modified: 2013-08-15 15:35 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-07-23 12:31:08 PDT
There are some files that no-rights content processes need access to, like omni.ja.  When we fork the content process, we should hand it these fds beforehand, before we cut off their access to the file system.

Assigning to Guillaume because he has most of the code to do this already.
Comment 1 Andrew Overholt [:overholt] 2012-07-31 13:20:47 PDT
I forget why we're blocked on input here.  Can anyone enlighten me?
Comment 2 Guillaume Destuynder [:kang] (NEEDINFO to ensure replies) 2012-09-07 07:20:15 PDT
For omni.jar (grepOmni and appOmni) i only found it in XRE_InitCommandLine() at gecko/toolkit/xre/nsAppRunner.cpp.  Ie, that's opened from the child process instead of passing a FD.

I initialize the sandbox (which cuts off access to the filesystem) inside ContentProcess::Init(), after mContent.InitXPCOM(), which, as far as I understand, is run after XRE_InitCommandLine()

If not, the sandbox that cuts off file system access can be initialized elsewhere, too. Once initialized we just can't go back.

We can also initialize it before exec'ing the child process (the restrictions are inherited), but that means all fds need to be opened and passed before hand, which might be a quite large code modification.

Additionally, apps like the camera attempt to open:
/vendor/lib/hw/ and /vendor/lib/ (Nexus S)

I'm auditing them with:

strace -p <PID>  -xx -s64 -e trace=file

And the regular:
ls -l /proc/<PID>/fd/
For open fds.
Comment 3 Andrew Overholt [:overholt] 2012-09-17 14:44:48 PDT
Clearing blocked-on-input since I have no idea why I put it there :)
Comment 4 Doug Turner (:dougt) 2012-09-28 14:06:43 PDT
discussed - "Not going to make v1, k9o blockers".
Comment 5 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-09-28 14:16:58 PDT
This is needed for OS level strong sandboxing, which won't make v1.
Comment 6 Guillaume Destuynder [:kang] (NEEDINFO to ensure replies) 2013-08-15 15:35:30 PDT
this is AFAIK no longer needed.
the privileges are set after the process has been started and initialized, effectively giving us a similar security level.

see also bug 862082 and bug 790923

as usual, feel free to reopen if this becomes an issue, or if desktop sandboxing for other platforms needs it (in this case, please change the assignee as well)

Note You need to log in before you can comment on or make changes to this bug.