Closed Bug 1158849 Opened 5 years ago Closed 5 years ago

Thumbnail content process on Windows is being sandboxed by mistake.

Categories

(Core :: Security: Process Sandboxing, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla40
Tracking Status
firefox37 --- wontfix
firefox38 --- fixed
firefox38.0.5 --- fixed
firefox39 --- fixed
firefox40 --- verified
firefox-esr38 --- verified

People

(Reporter: bobowen, Assigned: bobowen)

Details

Attachments

(1 file)

I've recently realised that the thumbnail content process is being sandboxed everywhere because the content sandbox is turned on in all channels.
This is simply because at the time I made that change, I didn't realise that the content process was being used at all.
So I changed it to all channels thinking that it would roll out when e10s did.

This may well not be causing any issues for most platforms, but the WinXP 64-bit sandbox currently fails to start, so it's certainly affecting that.

I'm going to change this to Nightly only for the moment.
Attachment #8598055 - Flags: review?(mh+mozilla) → review+
https://hg.mozilla.org/mozilla-central/rev/786d3ff3e82f
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Comment on attachment 8598055 [details] [diff] [review]
Only enable Windows content sandbox on Nightly because of thumbnail process.

Approval Request Comment
[Feature/regressing bug #]:
Bug 928044

[User impact if declined]:
The thumbnail content process will continue to fail to start for WinXP 64-bit users.
Also, there is a possibility that the sandbox is contributing to other crashes, but with no real benefit given the weak sandbox policy.

[Describe test coverage new/current, TreeHerder]:
This essentially falls back to the old chromium code for starting child processes, which is what was used until Fx37 and is still used for NPAPI processes.

Also I have applied this patch to a local version of Aurora and Beta and made sure that the thumbnail process starts correctly without sandboxing.

[Risks and why]:
Low - this is changing back to the Fx36 way of starting the process.

[String/UUID change made/needed]:
None
Attachment #8598055 - Flags: approval-mozilla-beta?
Attachment #8598055 - Flags: approval-mozilla-aurora?
Just to be clear I think this should go to 38 and 38.05.
Comment on attachment 8598055 [details] [diff] [review]
Only enable Windows content sandbox on Nightly because of thumbnail process.

[Triage Comment]
Should be in 38 rc1
Attachment #8598055 - Flags: approval-mozilla-release+
Attachment #8598055 - Flags: approval-mozilla-beta?
Attachment #8598055 - Flags: approval-mozilla-aurora?
Attachment #8598055 - Flags: approval-mozilla-aurora+
Bob, do you have some detailed steps to verify this fix with ESR 38?
Flags: needinfo?(bobowen.code)
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #11)
> Bob, do you have some detailed steps to verify this fix with ESR 38?

You can trigger the thumbnail content process with these instructions:
https://blog.mozilla.org/nnethercote/2013/10/22/how-to-trigger-a-child-process-in-desktop-firefox/

If you then look at the command line of the plugin-container.exe process using Process Explorer, it should not have the "-sandbox" parameter.

If you check a child process from Nightly with e10s it will have this parameter.
Flags: needinfo?(bobowen.code)
Reproduced with Firefox 37RC under Win 7 64-bit.
With Firefox 38.0ESR "-sandbox" parameter is not displayed, while on Nightly 40.0a1 2015-05-05 it is shown. 

Marking as verified these two versions.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.