1480122 - Sandbox breaks with developer build and non-canonical objdir path

Status: NEW

(Core :: Security: Process Sandboxing, defect, P3)

Description

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

I copied a mozconfig from Linux to OS X, featuring this line:

mk_add_options MOZ_OBJDIR=$HOME/src/obj.gecko-dev/obj-@CONFIG_GUESS@

But on this Mac, $HOME/src is a symlink to /Volumes/src (a case-sensitive volume).  Content processes all crashed on startup, thusly:

Hit MOZ_CRASH(LoadSheetSync failed with error 80520015 loading built-in stylesheet 'resource://gre-resources/counterstyles.css') at /Volumes
/src/gecko-dev/layout/style/nsLayoutStylesheetCache.cpp:734

There were also some other errors about frame scripts and 0x80520015 (== nsresult::NS_ERROR_FILE_ACCESS_DENIED).  Turning off the content sandbox fixed it.  Sandbox logging wasn't working for some reason, but running with MOZ_LOG=nsResProtocol:5 showed the path it was trying to access, which was under /Users/jld/src.

Attaching with LLDB and calling `open` (or rather `(int(*)(const char*, int))&__open`, because `open` was resolving to an XPCOM atom pointer for some reason?) showed that it couldn't open that path, but if I fixed the start of the path to use /Volumes/src it worked.

Meanwhile, the path used in the policy as TESTING_READ_PATH4 *was* canonicalized.

--

So I think what's going on is that reading the symlink isn't allowed by the sandbox policy, and therefore paths that traverse it also aren't allowed.

I don't know if it's worth fixing this, but I thought I'd file a bug just so it's recorded.  Having the build system call `os.path.realpath` on the objdir would do it, but that might have side effects.  It would also be possible to warn if the objdir isn't equal to its realpath, or assert that the objdir is accessible after starting the sandbox.