Closed Bug 1369669 Opened 2 years ago Closed 2 years ago

Unable to preview files from google drive

Categories

(Core :: Security: Process Sandboxing, defect)

55 Branch
All
Windows
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla56
Tracking Status
firefox53 --- unaffected
firefox54 --- unaffected
firefox55 --- disabled
firefox56 --- verified

People

(Reporter: bogdan_maris, Assigned: bobowen)

References

Details

(Whiteboard: sbwc2)

Attachments

(2 files)

Attached image Gif showing the issue
[Affected versions]:
- Latest Nightly 55.0a1

[Affected platforms]:
- Windows 7 64bit

[Steps to reproduce]:
1. Make Windows Users directory on junction point
2. Install Firefox and open it
3. Change `security.sandbox.content.level` value to `3`
3. Visit a file that has preview in google drive (mp3, pdf, txt, html etc)
eg: https://drive.google.com/file/d/0B-cUbHVNThEKQmtqVEtNeVZNdEU/view

[Expected result]:
- Preview of the file can be seen in Firefox

[Actual result]:
- Blank page is displayed in Firefox

[Regression range]:
- Not sure if this is a regression, could not find a bug where this value of the pref was first introduced. Also the nature of the steps would mean that I should try and manually find a regression which is very time consuming.

[Additional notes]:
- Not sure if Windows 10 is also affected we had trouble setting up the environment on the machine that runs it.
- Here is the browser console output for the same nightly with security.sandbox.content.level set to 2 and 3: https://pastebin.com/KmK6iiBK
- Gif attached showing the issue
- Not entirely sure if this is the right component for this issue, please change it if necessary.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1369670
Hi Bob,

This issue is still reproducible on Firefox 56.0a1 (2017-07-21), using the STR from Comment 0 and using the same environment.
Since Bug 1369670 is no longer reproducible, I would say that this is not a duplicate of that bug. Should I reopen this one, or is recommended to open a new bug for this issue?
Flags: needinfo?(bobowencode)
(In reply to Mihai Boldan, QA [:mboldan] from comment #2)
> Hi Bob,
> 
> This issue is still reproducible on Firefox 56.0a1 (2017-07-21), using the
> STR from Comment 0 and using the same environment.
> Since Bug 1369670 is no longer reproducible, I would say that this is not a
> duplicate of that bug. Should I reopen this one, or is recommended to open a
> new bug for this issue?

OK I've managed to reproduce this, but only if I block the install from admin rights and it gets installed in AppData\Local
Is this where you are installing Firefox?

This sound similar to a problem we've seen in release (bug 1316665).
Status: RESOLVED → REOPENED
Flags: needinfo?(bobowencode) → needinfo?(mihai.boldan)
Resolution: DUPLICATE → ---
(In reply to Bob Owen (:bobowen) from comment #3)
> (In reply to Mihai Boldan, QA [:mboldan] from comment #2)
> > Hi Bob,
> > 
> > This issue is still reproducible on Firefox 56.0a1 (2017-07-21), using the
> > STR from Comment 0 and using the same environment.
> > Since Bug 1369670 is no longer reproducible, I would say that this is not a
> > duplicate of that bug. Should I reopen this one, or is recommended to open a
> > new bug for this issue?
> 
> OK I've managed to reproduce this, but only if I block the install from
> admin rights and it gets installed in AppData\Local
> Is this where you are installing Firefox?
> 
> This sound similar to a problem we've seen in release (bug 1316665).

It seems that this issue is reproducible if Firefox is not installed in it's default location. 
This issue is not reproducible for stub.installer build, since there is no option for a custom installation.
It's reproducible if using both x32 or x64 installer.exe and install Firefox in a custom location (eg. Desktop), or by using the .zip file in order to start latest Nightly.
Please let me know if I can help any further.
Flags: needinfo?(mihai.boldan) → needinfo?(bobowencode)
This is because the path to the exe when launching the child process has a junction point in it.
Therefore any later DLL loads from that dir happen with that path and fail the whitelisting rule.

I think we should be able to resolve the path before launching.
Assignee: nobody → bobowencode
Status: REOPENED → ASSIGNED
Flags: needinfo?(bobowencode)
Whiteboard: sbwc2
This is required so that DLL paths loaded after lockdown match policy rules.
Attachment #8891344 - Flags: review?(jmathies)
Attachment #8891344 - Flags: review?(jmathies) → review+
Pushed by bobowencode@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9804b2b94597
Resolve junction points and symlinks in the child executable path before launching. r=jimm
https://hg.mozilla.org/mozilla-central/rev/9804b2b94597
Status: ASSIGNED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
I managed to verify the issue on Firefox 56.0a1(2017-07-30), by installing FF in custom location and using the installer.exe builds (x32 and x64) and .zip builds(x32 and x64). Also I've tested the issue with the stub installer build.
Test were performed with:
- Users directory on junction point
- Roaming user
- Profile on junction point
- Profile on notwork drive
- Firefox on network drive.

I'm marking this issue verified Fixed.
Status: RESOLVED → VERIFIED
Sandbox is not level 3 in 55.
Depends on: 1385928
This patch appears to break mozregression on Windows. See bug 1385928.

Workaround is to run with |--pref security.sandbox.content.level:0| for now.
You need to log in before you can comment on or make changes to this bug.