1336703 - [e10s] Firefox does not render file URL from network drive path when opened on the same machine

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect)

Description

[Gary Sanders]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

[1] Enable multiprocess windows.
[2] Enter a file type URL / URI. For example: file://///hostname/shared_folder_name/test.html


Actual results:

The URL is NOT rendered. Instead, a blank page with white background is displayed. Right click on the page background does NOT display a context menu.


Expected results:

The page referenced by the file URL should be rendered. This has worked for years and it still works when multi-process is disabled.

Comment 1

[Gary Sanders]

To be clearer about the precise problem reported: The file URL works when a direct file path is used, but does not work in multiprocess when a network file share is specified.

This works:
file:///c:/folder_name/test.html

This does not work:
file://///hostname/shared_folder_name/test.html

Comment 2

[Dragana Damjanovic [:dragana]]

Valentin, can you take a look? (URIs :) )

Comment 3

[Valentin Gosu [:valentin] (he/him)]

This isn't actually a URI bug. The remote file just fails to load. Michal, weren't you working on similar bug a while ago?

Comment 4

[Michal Novotny [:michal]]

That was bug 922481 which was WONTFIXed. See comment #11. It seems that bug 1147911 doesn't cover this case.

Comment 5

[Bob Owen (:bobowen)]

I've recently landed a change on Beta that changed the access token restrictions on the content process.
(These were more restrictive than I originally thought and caused issues on some edge cases.)

Gary, would you mind testing the latest Beta version to see if this is fixed?
https://www.mozilla.org/en-US/firefox/channel/desktop/

Not sure if you've used separate profiles before, but if you run Firefox Beta as follows, you can create a separate profile for testing:

firefox.exe -no-remote -P

Comment 6

[Gary Sanders]

(In reply to Bob Owen (:bobowen) (PTO until 25th Feb) from comment #5)
> I've recently landed a change on Beta that changed the access token
> restrictions on the content process.
> (These were more restrictive than I originally thought and caused issues on
> some edge cases.)
> 
> Gary, would you mind testing the latest Beta version to see if this is fixed?
> https://www.mozilla.org/en-US/firefox/channel/desktop/
> 
> Not sure if you've used separate profiles before, but if you run Firefox
> Beta as follows, you can create a separate profile for testing:
> 
> firefox.exe -no-remote -P

Tried this on Firefox 52.0b6 (32 bit), but unfortunately it still does not work.

The behavior, however, has changed. Rather than it loading a blank page, it never completes loading. The loading cursor on the tab just keeps spinning. To be sure, I copied and pasted the same link into IE and Edge and it loads.

Comment 7

[Bob Owen (:bobowen)]

(In reply to Gary Sanders from comment #6)
> (In reply to Bob Owen (:bobowen) (PTO until 25th Feb) from comment #5)

> Tried this on Firefox 52.0b6 (32 bit), but unfortunately it still does not
> work.
> 
> The behavior, however, has changed. Rather than it loading a blank page, it
> never completes loading. The loading cursor on the tab just keeps spinning.
> To be sure, I copied and pasted the same link into IE and Edge and it loads.

I can only guess that it is the low integrity setting that is interfering with loading this for some reason.
Can you confirm it is the sandbox by setting the pref security.sandbox.content.level=0 and restarting Firefox.
(It should be 1 at the moment.)

Unfortunately I can't reproduce this on Win7 or 10, do you have any details of how the network share is set-up?

Comment 8

[Gary Sanders]

(In reply to Bob Owen (:bobowen) (PTO until 25th Feb) from comment #7)
> (In reply to Gary Sanders from comment #6)
> > (In reply to Bob Owen (:bobowen) (PTO until 25th Feb) from comment #5)
> 
> > Tried this on Firefox 52.0b6 (32 bit), but unfortunately it still does not
> > work.
> > 
> > The behavior, however, has changed. Rather than it loading a blank page, it
> > never completes loading. The loading cursor on the tab just keeps spinning.
> > To be sure, I copied and pasted the same link into IE and Edge and it loads.
> 
> I can only guess that it is the low integrity setting that is interfering
> with loading this for some reason.
> Can you confirm it is the sandbox by setting the pref
> security.sandbox.content.level=0 and restarting Firefox.
> (It should be 1 at the moment.)
> 
> Unfortunately I can't reproduce this on Win7 or 10, do you have any details
> of how the network share is set-up?

When I set security.sandbox.content.level=0, it works. Set it back to value of 1 and it stops working. The network share was setup on Windows 10 from the directory properties dialog, sharing tab, share ... button. I tried providing read and write access, but that did not work, either.

Comment 9

[Bob Owen (:bobowen)]

Are you running Firefox on the same machine as the network share and accessing as such, instead of as a local drive?

I can reproduce this if I do that.

Comment 10

[Gary Sanders]

(In reply to Bob Owen (:bobowen) (PTO until 25th Feb) from comment #9)
> Are you running Firefox on the same machine as the network share and
> accessing as such, instead of as a local drive?
> 
> I can reproduce this if I do that.

Yes, I'm running Firefox on the same machine as the network share. I also use the same network share on other computers, but have not tried that out when running multi-process.

Comment 11

[Bob Owen (:bobowen)]

(In reply to Gary Sanders from comment #10)
> (In reply to Bob Owen (:bobowen) (PTO until 25th Feb) from comment #9)
> > Are you running Firefox on the same machine as the network share and
> > accessing as such, instead of as a local drive?
> > 
> > I can reproduce this if I do that.
> 
> Yes, I'm running Firefox on the same machine as the network share. I also
> use the same network share on other computers, but have not tried that out
> when running multi-process.

OK, it would be interesting to know if it works from a different computer I suspect it will.

We'll discuss this at our sandboxing meeting.

Comment 12

[Gary Sanders]

(In reply to Bob Owen (:bobowen) from comment #11)
> (In reply to Gary Sanders from comment #10)
> > (In reply to Bob Owen (:bobowen) (PTO until 25th Feb) from comment #9)
> > > Are you running Firefox on the same machine as the network share and
> > > accessing as such, instead of as a local drive?
> > > 
> > > I can reproduce this if I do that.
> > 
> > Yes, I'm running Firefox on the same machine as the network share. I also
> > use the same network share on other computers, but have not tried that out
> > when running multi-process.
> 
> OK, it would be interesting to know if it works from a different computer I
> suspect it will.
> 
> We'll discuss this at our sandboxing meeting.

Using Firefox 51.0.1 it does work from a different computer. To summarize as stated above, it is only when the file share is on the same computer that the UNC path does not work under e10s.

Comment 13

[Bob Owen (:bobowen)]

(In reply to Gary Sanders from comment #12)
> (In reply to Bob Owen (:bobowen) from comment #11)

> Using Firefox 51.0.1 it does work from a different computer. To summarize as
> stated above, it is only when the file share is on the same computer that
> the UNC path does not work under e10s.

Thanks for confirming that.
For the moment we don't have an easy way to fix this.

We think we'll need to proxy the opening of the file to the parent (or another privileged) process.
We want to do that at some point, but this is a pretty special case and the file could be opened with the normal local drive path.
So, I don't think this bug is going to push that work above other higher priority things at the moment, but hopefully we'll get to it fairly soon.

Comment 14

[Bob Owen (:bobowen)]

This has been fixed by the patches in bug 1344453.