Child content processes require certain directories to be marked as
readable or writeable when Sandboxing is enabled. The directories
to be whitelisted are saved in static variables in
sandboxBroker.cpp and are initialized in
SandboxBroker::GeckoDependentInitialize(). Any child content process
which is created before these directories are saved will be unable to
read or write to them.
The tor-launcher extension triggers the creation of a content process
which hosts the tor network configuration settings window. This process
is created before the whitelisted directories are saved. The network
settings process doesn't need access to these directories to function,
but subsequent content processes which are created once the settings
window exits do need these directories to function. Sometimes, the
creation of these subsequent processes is slow enough for the parent
process to 'catch up' and create the whitelist resulting in the broken
about:tor tab or broken white tab.
A previous iteration of this patch moved the GeckoDependentInitialize()
call directly above the call to DoStartup(). However, Mozilla dev Bob
Owen objected to this since this places the call before various
services are initialized which the SandboxBroker may depend on. Some
experimentation would seem to confirm his objections: placing the
whitelist init just prior to DoStartup() results in an empty value for
the profile directory which prevents child processes reading the chrome
and extensions directory.
This patch inserts the GeckoDependentInitialize() call into DoStartup()
just after the profile directory is known and queryable by the
SandboxBroker, and before the 'profile-after-change' notification is
fired. It also reverts the temp fix which reduced the sandbox level to
2 on windows.