Passes the profile dir to the content process as a -profile CLI option so
that the correct profile dir can be used in the OS X content sandbox rules.
Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected from the
content process (apart from a few profile subdirectories) even when they
don't reside in ~/Library.
MozReview-Commit-ID: rrTcQwTNdT
--HG--
extra : rebase_source : d91d8939cabb0eed36b640766756548a790a301c
Passes the profile dir to the content process as a -profile CLI option so
that the correct profile dir can be used in the OS X content sandbox rules.
Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected from the
content process (apart from a few profile subdirectories) even when they
don't reside in ~/Library.
--HG--
extra : rebase_source : 7bf426f14f31b35c8b541e6d21183226db9836c7
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
Allow /System/Library/PrivateFrameworks/ to be read from the from the plugin sandbox.
--HG--
extra : rebase_source : 8b71b7daed4792d8ce67131819c90acb2f5891ea
Making readlink() always fail with EINVAL (the result of applying it
to a non-symlink) worked on B2G, but this is not the case on desktop.
(Note: originally the idea for the B2G file broker was that it would
ignore symlinks and map lstat to stat, so that behavior for readlink
would have been consistent, but as eventually implemented it does do
lstat as actual lstat.)
In particular, this seems to be causing something in the graphics
library stack to change what GL renderer it uses (?), and on some
systems the presence of the readlink->EINVAL rule causes it to load a
version of the llvmpipe software renderer with a crash bug, instead of
(we assume) some other driver that works.
jprof is an in-tree profiling tool that runs on Linux.
This fixes the error:
Sandbox: seccomp sandbox violation: pid 29698, syscall 38, args 0 140731305513136 0 830 22509600 1. Killing process.
Sandbox: crash reporter is disabled (or failed); trying stack trace:
Sandbox: frame #01: __GI_setitimer (/build/glibc-GKVZIf/glibc-2.23/time/../sysdeps/unix/syscall-template.S:84)
Sandbox: frame #02: startSignalCounter(unsigned long) (.../mozilla-central/mozilla/tools/jprof/stub/libmalloc.cpp:464)
which occurs during shutdown when running with jprof enabled via the
JPROF_FLAGS environment variable containing JP_DEFER without actually
sending the signal to start jprof. It presumably occurs sooner if jprof
is actually used either via JP_START or by senging a SIGPROF/SIGALRM.
With the patch, these steps run to completion.
MozReview-Commit-ID: Fx4tzEyqIj2
--HG--
extra : transplant_source : %2AU%15F%8A%C5%E6%1D%03%20%1B%F6W%E9%EB%DA%8F%E7f%5D
Adds content sandbox metadata to parent and child crash reports:
Includes the value of pref security.sandbox.content.level,
whether or not the system is capable of sandboxing, if the
sandbox was successfully turned on, and (on Linux systems)
the sandbox capabilities flags.
New crash report keys:
"ContentSandboxLevel" in parent and content
"ContentSandboxCapable" in parent
"ContentSandboxEnabled" in content
"ContentSandboxCapabilities" in content on Linux
Callers should use a UniquePtr to hold the platform handle.
MozReview-Commit-ID: 6BWnyAf4b3a
--HG--
extra : transplant_source : %26%CA%0D%28%08%9BT%97Z%A1%3Dq%CD%21%A1_%EFE%83%0E
extra : histedit_source : 77f8ed3d0fdec6cce0c95469130ade0fb547bb91
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
fork() will now fail with EPERM instead of crashing; see code comment
and bug for more info. Tested with GTK3 Oxygen theme and SCIM, which
both seem to work. Also verified that GMP child processes still crash
on fork().
--HG--
extra : rebase_source : 267c4cb892b691502a9d7760bca4d23fee3fe449
For some reason libfontconfig really Needs To Know.
MozReview-Commit-ID: KSET8D5h9xf
--HG--
extra : rebase_source : 10c5df6a4b8b85be120a9828686d0c63e3fff5d4
For 32-bit Linux 4.3+, always add socketcall dispatcher even if relevant
syscalls are known, because both entry points will exist.
See Linux kernel commit:
commit 9dea5dc921b5f4045a18c63eb92e84dc274d17eb
Author: Andy Lutomirski <luto@kernel.org>
Date: Tue Jul 14 15:24:24 2015 -0700
x86/entry/syscalls: Wire up 32-bit direct socket calls
MozReview-Commit-ID: I3GEvolGfsR
--HG--
extra : rebase_source : c358a6d39d9bf5701150e58f1002f6c6dc91cd6f
The preprocessor token HAVE_ANDROID_OS configures 'android_filesystem_config.h'
to include the correct header files from the environment.
MozReview-Commit-ID: oKwdjzDjij
The preprocessor token HAVE_ANDROID_OS configures 'android_filesystem_config.h'
to include the correct header files from the environment.
MozReview-Commit-ID: oKwdjzDjij
This also fixes a bug where we weren't setting parts of the policy correctly for levels 3 to 9.
MozReview-Commit-ID: IXsg2nGOqoa
--HG--
extra : rebase_source : 65c76a581dcd498c7d7d5b01e4f4e140acdb244f
We've decided supporting the small number of x86 machines
without SSE2 instructions is no longer worth the cost in
developer time nor the performance impact for other users.
https://groups.google.com/d/msg/mozilla.dev.platform/dZC39mj5V-s/Xt_UqZXkAAAJ
Set -arch:SSE2 by default on x86 if an arch hasn't already
been supplied. This ensures we'll continue to build with
the right instruction set if the compiler changes its default
in the future, while still allowing custom builds to set
a lower minimum.
Also updates the filter to strip all arch switches on win64
when building the sandbox. The 64-bit compiler doesn't
support -arch:SSE2 either.
MozReview-Commit-ID: JzTRGPn9vzI
The original changeset that is being backed out had comment:
Bug 1023941 - Part 2: Static-link the CRT into plugin-container.exe.
MozReview-Commit-ID: 1iPJghgd0t2
--HG--
extra : rebase_source : cbed4e43f51af8ea0c3adbfc150ed029fe0d0f57
It's an annotation that is used a lot, and should be used even more, so a
shorter name is better.
MozReview-Commit-ID: 1VS4Dney4WX
--HG--
extra : rebase_source : b26919c1b0fcb32e5339adeef5be5becae6032cf
Not all systems (i.e., Gonk) support CLOCK_MONOTONIC_COARSE and
CLOCK_REALTIME_COARSE. With this patch, we don't refer to them if
they are not supported.
There are a long tail of C4311 and C4312 warnings in VS2015. Rather than
wait until all of them are fixed to land VS2015, we're taking the easy
way out and disabling these warnings in every directory currently
exhibiting a warning. This is evil. But it is a lesser evil than
globally disabling C4311 and C4312. At least with this approach new
C4311 and C4312 warnings in directories that aren't suppressing them
shouldn't be introduced.
MozReview-Commit-ID: 2cwWrjMD6B9
--HG--
extra : rebase_source : 3e7b8ea042765fdf138f5ca93a0f9dab75a95fcd
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. But the warning
occurs in third party code, so my hands are tied.
MozReview-Commit-ID: A0UF2RHJzVo
--HG--
extra : rebase_source : 3fc5300f6f67274162f4d65fd83eb9c18b4bf716
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. But the warning
occurs in third party code, so my hands are tied.
MozReview-Commit-ID: BCXQcEejre9
--HG--
extra : rebase_source : a36a432edc834ec806dd4341f247143b178902a4
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. But the warning
occurs in third party code, so my hands are tied.
MozReview-Commit-ID: 6n8nl517Ly
--HG--
extra : rebase_source : 19c1c012e1ddf15accbdf1a1050e4d607f9c7b31
Modify the Mac sandbox to allow temporary files to be created in a
parent-specified subdirectory of NS_OS_TEMP_DIR. This is similar to the
Windows approach. The parent provides a UUID in a preference which is
used by the content process to form the subdirectory name.
MozReview-Commit-ID: 6BONpfZz8ZI
--HG--
extra : rebase_source : ad18e091918356a1a40c13f1453972b4512ad476
From Chromium commit comment:
Sandbox: Add support for file system policies that use implied device paths.
A policy rule of the form \HarddiskVolume0\Foo\bar allows sandboxed code
to use \\.\HarddiskVolume0\Foo\bar directly.
Gian-Carlo Pascutto
Wes Kocher
Haik Aftandilian
Kan-Ru Chen
Jed Davis
Carsten "Tomcat" Book
Alexandre Lissy
L. David Baron
Julian Seward
Julian Hector
Fabrice Desré
Bob Owen
Wei-Cheng Pan
Tom Tromey
Thomas Zimmermann
Sebastian Hengst
Gabor Krizsanits
Ryan VanderMeulen
Ralph Giles
Chris Peterson
Nicholas Nethercote
Chris Pearce
Gregory Szorc
Boris Zbarsky
Daniel Holbert
Ehsan Akhgari
Sylvestre Ledru
Birunthan Mohanathas