1375955 - security.sandbox.content.level 2 getting in the way of debugging on Windows

Status: NEW

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

Description

[Milan Sreckovic [:milan] (needinfo for best results)]

There are three things that don't work for me with the default value for security.sandbox.content.level (2) vs. setting it to zero.  I have them all in this bug, but they may turn out to be separate issues and needing separate bugs.

Put a MOZ_ASSERT(false) at the start of ContentChild::RecvSetXPCOMProcessAttributes - we want a crash early in the content process lifetime, then run the debug build with security.sandbox.content.level set to 2 and 0.

1. When launched from the command line (mozilla-build bash), the content process crash stacks don't show up in it for "2", but show up for "0".

2. MOZ_DEBUG_CHILD_PAUSE does not show the process ID in the window, and seemingly doesn't pause either for "2", but shows up for "0".

3. MS Child Process Debugging Tool extension to Visual Studio (https://blogs.msdn.microsoft.com/devops/2014/11/24/introducing-the-child-process-debugging-power-tool/ - note that it requires enabling after installation) doesn't properly work.  Starting firefox from Visual Studio, with "2", we just get the sad face crashed tab; with "0", we actually break in the debugger, because we automatically attached to the child process.

Comment 1

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

(Assuming this is Windows from the references to “mozilla-build bash” and Visual Studio.)