Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
The services.* preferences branch gets sanitizer by default. Exceptions
need to be added in the ShouldSanitizePreference method.
services.settings.loglevel got added in bug 1840851.
services.settings.preview_enabled got added in bug 1780403.
Differential Revision: https://phabricator.services.mozilla.com/D183442
In mozilla-central before this patch, we had a boilerplate
NS_ENSURE_SUCCESS(rv, rv) after our call to GetObserverService()
This expression *does not actually test whether GetObserverService() succeeded*
though, since GetObserverService doesn't touch rv! When GetObserverService()
fails, it just returns nullptr. So we should be testing it for success with a
null-check.
In fact, we did *used to* test for success with a null-check, but that was
replaced by this ineffective NS_ENSURE_SUCCESS by accident in Bug 1276488, as
part of a large patch that was geared at adding diagnostics.
So: let's just restore the null-check. It's unlikely to be tripped, since
GetObserverService only returns nullptr at xpcom shutdown time (and this code
runs at startup); but explicitly handling that by returning a failure code
seems to be the right thing to do. And more importantly, the NS_ENSURE_SUCCESS
can be made to misfire if we happen to have a stray error code from some
earlier call remaining in 'rv'.
Differential Revision: https://phabricator.services.mozilla.com/D174544
Preferences from /etc/firefox/defaults/pref overwrites preferences set in omni.jar
and firefox/defaults/pref. The code was used for flatpak and snap only, but it could
be used also for regular Linux builds.
Differential Revision: https://phabricator.services.mozilla.com/D168799
Preferences from /etc/firefox/defaults/pref overwrites preferences set in omni.jar
and firefox/defaults/pref. The code was used for flatpak and snap only, but it could
be used also for regular Linux builds.
Differential Revision: https://phabricator.services.mozilla.com/D168799
1. Ship the Sanitization (currently on in Nightly
but without crashing) to the trains
2. Enabling crashing in Nightly
#1 will start omitting the preference values in
Content Processes. An affected user will have
their browser behave differently - it will be as
if the preference has no value. So for e.g. the
font preferences, their font customizations will
be gone. If they file a bug about this happening
and an engineer connects the problem to pref
sanitization we could debug the issue and maybe
understand it.
#2 will mean that an affected user (of which
there are currently none we think) will have a
content process crash when they access a
forbidden preference. The crash reason will
contain the name of the preference, and the
stack which would help us better understand
why we crashed.
Differential Revision: https://phabricator.services.mozilla.com/D167287
These can be set by users, and callers often don't do a great job of
handling errors, so maintaining the existing error behaviour is our
safest option here. In addition, there are some tests which set prefs to
very large values, resulting in `inf` being used as the returned
preference value.
In the future it may be nice to make the error handling behaviour act
more consistently with other branches (not clobbering the outparam on
error), though that was left out from this change.
Differential Revision: https://phabricator.services.mozilla.com/D148306
- Do not allow preallocated processed to turn into Privileged
About Content Processes
- Separate ShouldSanitizePreference into a more logical
'ShouldSanitizePreference' to use when sending a process to
a subprocess, and a separate IsPreferenceSanitized to be used
when accessing a preference
- Remove several now-redundant parts of conditionals like
- gContentProcessPrefsAreInited (now inside IsPreferenceSanitized)
- !XRE_IsParentProcess() (now inherent in the check)
- Remove the aIsDestinationWebContentProcess argument - it's not
needed in IsPreferenceSanitized, and can be checked outside
ShouldSanitizePreference
The original (partial) preference omitting code was done for
performance, and stuck around partially in the sanitization code -
preferences explicitly blocklisted were omitted from all
sub-processes. But those preferences changed from large preferences
to privacy-sensitive ones and with this change we no longer omit
any preferences from all sub-processes, we only sanitize some
preferences for web content processes.
We could bring back this performance behavior though, and tailor
it specifically for performance and not privacy.
Differential Revision: https://phabricator.services.mozilla.com/D159940
