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.
I forget why we're blocked on input here. Can anyone enlighten me?
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/camera.herring.so and /vendor/lib/libs3cjpeg.so (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.
Clearing blocked-on-input since I have no idea why I put it there :)
discussed - "Not going to make v1, k9o blockers".
This is needed for OS level strong sandboxing, which won't make v1.
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)