Closed
Bug 1369669
Opened 7 years ago
Closed 7 years ago
Unable to preview files from google drive
Categories
(Core :: Security: Process Sandboxing, defect)
Tracking
()
VERIFIED
FIXED
mozilla56
Tracking | Status | |
---|---|---|
firefox53 | --- | unaffected |
firefox54 | --- | unaffected |
firefox55 | --- | disabled |
firefox56 | --- | verified |
People
(Reporter: bmaris, Assigned: bobowen)
References
Details
(Whiteboard: sbwc2)
Attachments
(2 files)
857.15 KB,
image/gif
|
Details | |
1.44 KB,
patch
|
jimm
:
review+
|
Details | Diff | Splinter Review |
[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.
Assignee | ||
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Comment 2•7 years ago
|
||
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)
Assignee | ||
Comment 3•7 years ago
|
||
(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 → ---
Comment 4•7 years ago
|
||
(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)
Assignee | ||
Comment 5•7 years ago
|
||
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
Updated•7 years ago
|
status-firefox56:
--- → affected
Assignee | ||
Comment 6•7 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d9a6363e244bf601e5e89df5f2009f2e1311a3ce
Assignee | ||
Comment 7•7 years ago
|
||
This is required so that DLL paths loaded after lockdown match policy rules.
Attachment #8891344 -
Flags: review?(jmathies)
Updated•7 years ago
|
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
Comment 9•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/9804b2b94597
Status: ASSIGNED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Comment 10•7 years ago
|
||
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
Comment 11•7 years ago
|
||
Sandbox is not level 3 in 55.
Comment 12•7 years ago
|
||
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.
Description
•