PulseAudio is the only thing that's known to need this. Note that the
same file often exists as /etc/machine-id, and we currently allow reading
all of /etc (which includes other fingerprinting hazards as well).
MozReview-Commit-ID: FoyKQzhAV6M
--HG--
extra : rebase_source : 593ee0b94cf507681a034d22cd06a9050d56b86a
If these aren't close-on-exec, they can be inherited by the crash
reporter process after the parent process has crashed and exited,
causing child processes to continue running when the IPC I/O thread blocks
in the file broker trying to open a GeckoChildCrash temp file.
(Empirically, the main thread then blocks waiting for the I/O thread.)
Operations that run on dedicated threads, like playing media, may
continue even though the main and IPC threads are locked up, resulting in
videos that keep playing sound even though the browser seems to no longer
exist.
If the broker socket is closed as expected when the parent process
exits, the child will return failure from the brokered file operation
and then go on to get an IPC error due to the parent process's
nonexistence, and will exit as normal.
This patch makes the same change to rejected syscall reporting, even
though that's a one-way asynchronous message with no response to wait
for, just in case something goes wrong enough to fill the entire socket
buffer but not so badly broken that it would wind up in an infinite loop
anyway.
SOCK_CLOEXEC has been present since Linux 2.6.26, and it would be used
only if seccomp-bpf is available, so it should be safe to use
unconditionally.
MozReview-Commit-ID: 7tDPBJILzlj
--HG--
extra : rebase_source : b797655dff2eea88c406d83dcee4a859f2a038b7
As a special case to deal with PulseAudio, testing for a process's
existence with kill(pid, 0) quietly fails with EPERM instead.
(I also added some commentary on umask, since I was touching that part of
the code anyway.)
MozReview-Commit-ID: CM0Aqii13j4
--HG--
extra : rebase_source : 44ef05e9a39a9eea4a649399c63b865f5523d43b
Generally, the intent for the Add* methods is that they always grant
rights in addition to what's already in the policy, not remove them;
this makes subtree rules that overlap single-file rules follow that
principle.
This requires a global analysis because the conflicting rules can be
added in any order. It does not currently attempt to handle prefix
rules that aren't at a path component boundary, because that's not a
problem we currently have.
MozReview-Commit-ID: 4kv6QoGCBTV
--HG--
extra : rebase_source : 9e41263bbb1c07b8cde40ec2e72d746f17278fcb
Now that all of the operations that took two paths are removed, we can
have less string manipulation running on untrusted inputs in a trusted
context.
Note that the path isn't null-terminated in transit, because we know
the message length and there's no longer any need to delimit anything.
(This is how the protocol worked before the two-path operations were
added.)
MozReview-Commit-ID: 5VHkMoPlWmU
--HG--
extra : rebase_source : 2108a4f7c7bf5098f2ef63786c3675367bd56e19
In testing (local and CI) these seem to no longer be used.
MozReview-Commit-ID: 2D3C8eWoIsB
--HG--
extra : rebase_source : dde2015af1d036c32631d185703f1149285b253e
Now that all of the operations that took two paths are removed, we can
have less string manipulation running on untrusted inputs in a trusted
context.
Note that the path isn't null-terminated in transit, because we know
the message length and there's no longer any need to delimit anything.
(This is how the protocol worked before the two-path operations were
added.)
MozReview-Commit-ID: 5VHkMoPlWmU
--HG--
extra : rebase_source : 74fd595c4aea6c9e073ae704b8e59599770300b4
In testing (local and CI) these seem to no longer be used.
MozReview-Commit-ID: 2D3C8eWoIsB
--HG--
extra : rebase_source : 20d986e1430a70ddb534fdd73d1d06e12510292f
1. X_OK is now allowed, and is limited only by the MAY_ACCESS permission.
2. The actual access() syscall is now used, if access is granted by the
broker policy. This fixed bug 1382246, which explains the background.
MozReview-Commit-ID: 926429PlBnL
--HG--
extra : rebase_source : 6ae54c4c25e1389fa3af75b0bdf727323448294a
MozStackWalk() is different on Windows to the other platforms. It has two extra
arguments, which can be used to walk the stack of a different thread.
This patch makes those differences clearer. Instead of having a single function
and forbidding those two arguments on non-Windows, it removes those arguments
from MozStackWalk, and splits off MozStackWalkThread() which retains them. This
also allows those arguments to have more appropriate types (HANDLE instead of
uintptr_t; CONTEXT* instead of than void*) and names (aContext instead of
aPlatformData).
The patch also removes unnecessary reinterpret_casts for the aClosure argument
at a couple of MozStackWalk() callsites.
--HG--
extra : rebase_source : 111ab7d6426d7be921facc2264f6db86c501d127
This is similar like the previous patch, but for the 8-bit string variants.
Also, it changes assignment to Adopt() in GetCString() and GetDefaultCString()
to avoid an extra copy.
--HG--
extra : rebase_source : eba805c3a7b809d5ccd6e853b1c9010db9477667
Otherwise, a warning is triggered because the statement will never be executed [-
Found with -Wswitch-unreachable with gcc 7
MozReview-Commit-ID: FVStzyFlhJp
--HG--
extra : rebase_source : 1db87153c3e7dcde8d5a9e0f1f0ff607307c9ca2
Jed Davis
Gian-Carlo Pascutto
Chris Manchester
Phil Ringnalda
Chris Peterson
Sylvestre Ledru
Sebastian Hengst
Wes Kocher
Nicholas Nethercote
Thomas Daede