MOZ_CRASH(Hit fatal chromium sandbox condition.) on local build because of file system junction

RESOLVED FIXED in Firefox 66

Status

()

defect
P2
normal
RESOLVED FIXED
9 months ago
5 months ago

People

(Reporter: JanH, Assigned: bobowen)

Tracking

Trunk
mozilla66
Desktop
Windows
Points:
---

Firefox Tracking Flags

(firefox64 wontfix, firefox65 wontfix, firefox66 fixed)

Details

Attachments

(1 attachment)

> firefox.exe!logging::LogMessage::~LogMessage() Zeile 120	C++
> firefox.exe!sandbox::FileSystemPolicy::GenerateRules(const wchar_t * name, sandbox::TargetPolicy::Semantics semantics, sandbox::LowLevelPolicy * policy) Zeile 92	C++
> firefox.exe!sandbox::PolicyBase::AddRuleInternal(sandbox::TargetPolicy::SubSystem subsystem, sandbox::TargetPolicy::Semantics semantics, const wchar_t * pattern) Zeile 708	C++
> firefox.exe!sandbox::PolicyBase::AddRule(sandbox::TargetPolicy::SubSystem subsystem, sandbox::TargetPolicy::Semantics semantics, const wchar_t * pattern) Zeile 389	C++
> xul.dll!mozilla::AddCachedDirRule(sandbox::TargetPolicy * aPolicy, sandbox::TargetPolicy::Semantics aAccess, const mozilla::UniquePtr<nsTString<char16_t>,mozilla::DefaultDelete<nsTString<char16_t> > > & aBaseDir, const nsTLiteralString<char16_t> & aRelativePath) Zeile 282	C++
> xul.dll!mozilla::SandboxBroker::SetSecurityLevelForContentProcess(int aSandboxLevel, bool aIsFileProcess) Zeile 505	C++
> xul.dll!mozilla::ipc::GeckoChildProcessHost::PerformAsyncLaunchInternal(std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > & aExtraOpts) Zeile 949	C++
> xul.dll!mozilla::ipc::GeckoChildProcessHost::PerformAsyncLaunch(std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > aExtraOpts) Zeile 547	C++
> xul.dll!mozilla::ipc::GeckoChildProcessHost::RunPerformAsyncLaunch(std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > aExtraOpts) Zeile 555	C++

The crash-triggering call of FileSystemPolicy::GenerateRules is being done with a name of "d:\\Users\\Jan\\AppData\\Roaming\\Mozilla\\SystemExtensionsDev\\*" and semantics of "FILES_ALLOW_READONLY (1)". Because a comment there mentions reparse points [1], I'm guessing that this problem is being hit because I used an NTFS file system junction to move AppData\Roaming\Mozilla onto an additional SSD drive I recently installed in my computer.

[1] https://dxr.mozilla.org/mozilla-central/rev/c2e3be6a1dd352b969a45f0b85e87674e24ad284/security/sandbox/chromium/sandbox/win/src/filesystem_policy.cc#90-92
Assignee

Updated

9 months ago
Flags: needinfo?(bobowencode)
Assignee

Comment 1

9 months ago
Yes, that will probably be it.
At the moment, we set up rules to access the chrome directory in the profile and various extension directories.
The sandbox code doesn't allow those rules to be reparse points, which includes junction points.

I had to make a change to resolve the bin directory for similar reasons, so we'll probably have to do the same for the profile dir.
It has to be done in the directory service, so that the requests from the child process will match the rules we set up.

As a work around, if you change the path to the real one in profiles.ini (setting IsRelative=0), does that fix the problem?
Flags: needinfo?(bobowencode) → needinfo?(jh+bugzilla)
I don't think your suggestion would help: The (first) faulting path is %appdata%\Mozilla\SystemExtensionsDev, i.e. nothing that looks like it would be controlled by profiles.ini. (Also the actual profile itself that is used by the local build is within the objdir anyway, so not affected by any junctions in my case).
As a workaround, I've simply disabled the sandbox completely for my local builds.
Flags: needinfo?(jh+bugzilla)
Assignee

Comment 3

9 months ago
(In reply to Jan Henning [:JanH] from comment #2)
> I don't think your suggestion would help: The (first) faulting path is
> %appdata%\Mozilla\SystemExtensionsDev, i.e. nothing that looks like it would
> be controlled by profiles.ini. (Also the actual profile itself that is used
> by the local build is within the objdir anyway, so not affected by any
> junctions in my case).
> As a workaround, I've simply disabled the sandbox completely for my local
> builds.

Ah, I'd forgotten that not all of them were in the profile dir.
I'll try and pick this up soon.
Flags: needinfo?(bobowencode)
Assignee

Updated

9 months ago
Priority: -- → P2
Assignee

Comment 4

6 months ago
Hi Jan, sorry it's taken so long for me to look at this.

I've pushed a patch to try that resolves the junction points and symlinks for the systems extensions and dev dirs.

Would you be able to test this to see if it fixes the problem (I've not dealt with system extensions and couldn't find any docs about them):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=09d1904a05654a19e135b174f17fbc2f0384057e
Flags: needinfo?(bobowencode) → needinfo?(jh+bugzilla)
> I've not dealt with system extensions and couldn't find any docs about them

Neither have I, but I've re-enabled the sandbox in my mozconfig and with your patch applied, my local build no longer crashes, so thank you for looking at this.
Flags: needinfo?(jh+bugzilla)
Assignee

Comment 6

6 months ago
(In reply to Jan Henning [:JanH] from comment #5)
> > I've not dealt with system extensions and couldn't find any docs about them
> 
> Neither have I, but I've re-enabled the sandbox in my mozconfig and with
> your patch applied, my local build no longer crashes, so thank you for
> looking at this.

Ah, sorry I didn't realize that this was failing without doing systems extensions work.
Thanks for testing this.
Assignee

Comment 7

6 months ago
This is needed because they are currently used in sandbox rules.
Attachment #9031889 - Flags: review?(jmathies)
Assignee

Updated

6 months ago
Assignee: nobody → bobowencode
Status: NEW → ASSIGNED

Updated

5 months ago
Attachment #9031889 - Flags: review?(jmathies) → review+

Comment 8

5 months ago
Pushed by bobowencode@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5c1a8f06c28b
On Windows resolve junction points and symlinks in the sys user extensions directories. r=jimm

Comment 9

5 months ago
bugherder
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
You need to log in before you can comment on or make changes to this bug.