Closed Bug 1263069 Opened 4 years ago Closed 4 years ago

Fix process sandboxing of the temp directory to actually work

Categories

(Core :: Security: Process Sandboxing, defect)

defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1261751

People

(Reporter: jwatt, Assigned: jwatt)

Details

(Whiteboard: sbmc1)

Attachments

(1 file)

During startup I get a warning that we are not creating the sandboxed temp directory:

[48521] WARNING: Failed to delete temp directory.: file /Users/jonathan/moz/trees/i/toolkit/xre/nsAppRunner.cpp, line 626
[48521] WARNING: Failed to get or clean sandboxed temp directory.: file /Users/jonathan/moz/trees/i/toolkit/xre/nsAppRunner.cpp, line 702

It looks like this has been around since http://hg.mozilla.org/mozilla-central/rev/116d87a1a2a8 (bug 1162327) landed, so coming up for a year ago.

During startup we end up under:

  nsresultForErrno
  nsLocalFile::Remove
  GetAndCleanTempDir
  SetUpSandboxEnvironment
  XREMain::XRE_mainRun

The tempDir->Remove() call fails because |errno == 2|. nsresultForErrno converts that to NS_ERROR_FILE_TARGET_DOES_NOT_EXIST, and has done since before Mozilla moved from CVS to hg. On returning this error to GetAndCleanTempDir we hit the code:

  rv = tempDir->Remove(/* aRecursive */ true);
  if (NS_FAILED(rv) && rv != NS_ERROR_FILE_NOT_FOUND) {
    NS_WARNING("Failed to delete temp directory.");
    return nullptr;
  }

This is where things go wrong. The check against NS_ERROR_FILE_NOT_FOUND does not match NS_ERROR_FILE_TARGET_DOES_NOT_EXIST so we end up returning nullptr, which in turn causes SetUpSandboxEnvironment to skip creation of the NS_APP_CONTENT_PROCESS_TEMP_DIR.
Attached patch patchSplinter Review
Attachment #8739294 - Flags: review?(jmathies)
Attachment #8739294 - Flags: review?(jmathies)
Whiteboard: sbmc1
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1261751
No longer blocks: 1162327
You need to log in before you can comment on or make changes to this bug.