1402325 - Trying to load extension page results in "Access to the file was denied"

Status: RESOLVED DUPLICATE of bug 1393805

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

Description

[asteel]

Attachment: [e-mail]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36

Steps to reproduce:

1. Help > Troubleshooting Information > Refresh Firefox
2. Navigate to about:debugging#addons
3. Click 'Load Temporary Add-on' and select the attached XPI
4. Click the new toolbar button in the upper right
5. A panel showing 'Loaded!' should appear (resource://support-at-lastpass-dot-com/data/test.html)
6. Try to load the same page in a tab: resource://support-at-lastpass-dot-com/data/test.html



Actual results:

Access to the file was denied


Expected results:

The page should have loaded and 'Loaded!' should have been displayed

Comment 1

[YF (Yang)]

WFM in Fx55.0.3 & 56.0 on Win10.

Comment 2

[Adrian Florinescu [:aflorinescu]]

As expected, Nightly 58, Beta 57 - There was an error during installation: Add-on [e-mail] is not compatible with application version. add-on minVersion: 38.0a1. add-on maxVersion: *.

For Fx 55.0.3, Fx 56.0 it's a works for me as well on Win 10.


Asteel, is there something we are missing? Like a specific operating system or additional steps?

Since we cannot reproduce it, marking as WFM. Please reopen with additional information.

Comment 3

[Adrian Florinescu [:aflorinescu]]

Apologies, I actually missed the step 6, which was the thinghie we were supposed to see. So, I can't reproduce it in FF 55.0.3, but I can reproduce it on RC 6   -  	56.0 Build ID 20170926190823, therefore reopening the issue.

Comment 4

[asteel]

Thanks Adrian! I was just about to suggest trying on a Mac, but if it's reproducible on windows too all the better!

Comment 5

[Adrian Florinescu [:aflorinescu]]

More accurately, this is the changeset that introduced this regression: https://hg.mozilla.org/integration/mozilla-inbound/rev/5195f1b94903

Comment 6

[Haik Aftandilian [:haik]]

This is probably a duplicate of bug 1393805. With the stronger filesystem sandboxing in build 56 (for Windows and Mac), legacy extensions can't be temporarily installed from arbitrary locations on the filesystem. The equivalent sandboxing should come to Linux in/around build 57.

As a workaround, on Windows, could you try placing the extension in <user_home>\AppData\Roaming\Mozilla\Extensions and then installing?

On Mac, as a workaround use ~/Library/Application Support/Mozilla/Extensions.

Comment 7

[asteel]

I just tried the workaround and got the same results. I loaded the XPI from /Users/asteel/Library/Application%20Support/Mozilla/Extensions/[e-mail]-1.1.1%20(1).xpi

Comment 8

[Haik Aftandilian [:haik]]

(In reply to asteel from comment #7)
> I just tried the workaround and got the same results. I loaded the XPI from
> /Users/asteel/Library/Application%20Support/Mozilla/Extensions/
> [e-mail]-1.1.1%20(1).xpi

Which version of Firefox was that on? I'll post a screenshot of what it looks like for me. It installed for me on Mac FirefoxBeta 56.

Comment 9

[Haik Aftandilian [:haik]]

Attachment: Testing installing the XPI on Mac Beta 56

Comment 10

[asteel]

I was on Mac Beta 56 and tried to make sure it was the latest 56 beta, but it downloaded 57 beta instead. Going to revert back to 56 now and will show a screenshot. How can I post a screenshot in a comment like this though? I don't see a way.

Comment 11

[asteel]

Haik, I see your screenshot now, that is the working case that you showed. Try loading resource://support-at-lastpass-dot-com/data/test.html in a new tab. I wanted to show the positive case as well to show the file was really accessible.

Comment 12

[Haik Aftandilian [:haik]]

(In reply to asteel from comment #10)
> I was on Mac Beta 56 and tried to make sure it was the latest 56 beta, but
> it downloaded 57 beta instead.

Ah, bad timing. The Beta channel just transitioned to 57, but Release is still on 55 (release date for 56 is tomorrow.)

> Going to revert back to 56 now and will show
> a screenshot. How can I post a screenshot in a comment like this though? I
> don't see a way.

Use the "Attach File" link under the attachments section and add your comment from the attachment upload page.

Comment 13

[asteel]

Attachment: Access to the file was denied

Here's a screenshot of the issue in 56.0b9 (https://ftp.mozilla.org/pub/firefox/releases/56.0b9/mac/en-US/)

Comment 14

[Haik Aftandilian [:haik]]

(In reply to asteel from comment #11)
> Haik, I see your screenshot now, that is the working case that you showed.
> Try loading resource://support-at-lastpass-dot-com/data/test.html in a new
> tab. I wanted to show the positive case as well to show the file was really
> accessible.

OK, I can reproduce that problem and can see what's happening now. The regular expression in the Mac sandbox rules for this directory has a very old bug that is exposed on build 56 when the directory is used. Could you try adding a 1-character subdirectory within the Extensions directory? For example, from the terminal, I create a new directory named 'X' and put the XPI in there. It has to be a 1-character directory.

  $ mkdir ~/Library/Application\ Support/Mozilla/Extensions/X
  $ mv support\@lastpass.com-1.1.1.xpi ~/Library/Application\ Support/Mozilla/Extensions/X/

I'll file a new bug for the regular expression issue which is only going to affect Mac build 56 and legacy extensions placed in ~/Library/Application\ Support/Mozilla/Extensions/.

The plan with bug 1393805 is to provide a documented directory for developers to place legacy extension XPI's in for local development (to be loaded with about:debugging) for the next few releases until we've completely transitioned away from legacy extensions.

Comment 15

[asteel]

I'll confirm tomorrow once 56 is released :) My 56 test already auto-updated again.

Comment 16

[Haik Aftandilian [:haik]]

(In reply to asteel from comment #15)
> I'll confirm tomorrow once 56 is released :) My 56 test already auto-updated
> again.

OK, thanks.

My trick is to create a new no-updates profile and with Release Firefox and turn off auto-updates in the preferences. Then launch my 56 download and choose the new no-updates profile. That requires starting Firefox with -P so that the profile manager comes up first ("/Applications/Firefox.app/Contents/MacOS/firefox -P") and then deselecting "Use the selected profile without asking at startup".

Comment 17

[Panos Astithas (he/him) [:past] (please ni?)]

Jim, comment 14 and the progress in bug 1393805 make me think that this is wontfix/fix-optional for 56. What do you think?

Comment 18

[Haik Aftandilian [:haik]]

(In reply to Panos Astithas [:past] (56 Regression Engineering Owner) (please ni?) from comment #17)
> Jim, comment 14 and the progress in bug 1393805 make me think that this is
> wontfix/fix-optional for 56. What do you think?

I'll answer for Jim on this.

I've been meaning to close this as a duplicate of bug 1393805. Bug 1393805 is going to provide a sandbox-whitelisted directory that a legacy extension could be copied to first and then installed with about:debugging for development. If we can get that uplifted to 56, it will serve as a workaround for this problem in 56.

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking fix-optional to get this bug out of the regression triage (we are tracking it in bug 1393805)