1206404 - Unexpected error "SecurityError: The operation is insecure." when constructing a Worker in a file:/// document when the script file passed to the worker constructor does not exist

Status: RESOLVED FIXED

(Core :: DOM: Workers, defect)

Description

[Jukka Jylänki]

Attachment: operation_is_insecure.tar.gz

STR: Open not_well_formed/not_well_formed.html via a file:// URL (i.e. drag-drop to browser) and observe the error message in the console.

Observed: Console prints "SecurityError: The operation is insecure. f37f0335-50cb-f340-a585-a904574f02cb:2011:0" (ignore the other errors)

Expected: The problem is caused by a missing file pthread-main.js, and adding that file removes the error. How is a missing file a security error? Is the error message accidentally wrong - wouldn't it be better to give a 404 file not found type of error?

Comment 1

[:Gijs (he/him)]

Can't reproduce on 48 beta on OS X with the attached testcase. Do you still see this?

Comment 2

[ovidiu boca[:Ovidiu]]

Tested on Mac OS X10.10 with FF Nightly 50.0a1 and I can't see the error in browser console.

Comment 3

[Jukka Jylänki]

Yes, the error still occurs. Tested on both Windows and OS X with the latest Nightly as of today and current stable.

Comment 4

[:Gijs (he/him)]

(In reply to Jukka Jylänki from comment #3)
> Yes, the error still occurs. Tested on both Windows and OS X with the latest
> Nightly as of today and current stable.

On a clean profile? e10s on or off? We'll need to figure out why the rest of us can't reproduce what you're seeing before this is fixable, and this really needs triaging to whatever component is producing the error rather than just putting in 'general'.

Comment 5

[Jukka Jylänki]

Sorry, confused this with bug 1206403, which shares the test case with this one, and that one still reproduces.

Looks like bug 1205390 hid the original test case from working. Posting a new one in a moment.

Comment 6

[Jukka Jylänki]

Attachment: operation_is_insecure.zip

New test case.

Comment 7

[Jukka Jylänki]

In the new test case (needs Nightly with SharedArrayBuffer support), I notice that in current Nightly, the error message has changed from

SecurityError: The operation is insecure.

to

SecurityError: Failed to load worker script at "pthread-main.js"

The current form is now descriptive, that is what the code is attempting to do and the file is intentionally missing, however is that supposed to be labeled a SecurityError?

Comment 8

[:Gijs (he/him)]

(In reply to Jukka Jylänki from comment #7)
> In the new test case (needs Nightly with SharedArrayBuffer support), I
> notice that in current Nightly, the error message has changed from
> 
> SecurityError: The operation is insecure.
> 
> to
> 
> SecurityError: Failed to load worker script at "pthread-main.js"
> 
> The current form is now descriptive, that is what the code is attempting to
> do and the file is intentionally missing, however is that supposed to be
> labeled a SecurityError?

These are just different DOM error types. This is the spec:

https://html.spec.whatwg.org/multipage/workers.html#dom-worker

It doesn't specify, as best I can tell, what to do in this circumstance. In particular, it says:

"The user agent may throw a "SecurityError" DOMException and abort these steps if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to start dedicated workers)."

and

"If [parsing the URL argument into a full URL] fails, throw a "SyntaxError" DOMException and abort these steps."

but maybe constructing the Worker should succeed and it shouldn't error until https://html.spec.whatwg.org/multipage/workers.html#run-a-worker step 9 "Obtain script by switching on the value of options's type member:" ?

What do other browsers do? Does the behaviour change if the page is loaded over HTTP instead?

Comment 9

[Jukka Jylänki]

Loading over HTTP gives

NetworkError: Failed to load worker script at "pthread-main.js"

Not sure what the correct report would be, but if SecurityError sounds by design, I'm ok either way.

Comment 10

[Boris Zbarsky [:bzbarsky]]

The SecurityError case being hit here means that we got into the worker ReportLoadError function with NS_ERROR_DOM_BAD_URI as the nsresult.  In that situation we explicitly report it as a SecurityError.  Normally NS_ERROR_DOM_BAD_URI comes from failed same-origin checks, which is why it's treated as a security error.

I did try a basic testcase where I have an HTML page load a nonexistent worker URL and I get it reported as a NetworkError if the "security.fileuri.strict_origin_policy" preference is false, and a SecurityError if that preference is true (the default value).  The reason for that is that in nsPrincipal::MayLoadInternal (which is enforcing the "workers may only load same-origin stuff" security policy) we end up with the following logic flow (on Mac):

1)  The source and target are not same-origin, because under the strict file policy
    every file is a separate origin.
2)  We go to check for the strict file policy relaxation condition, which is that
    the target file's parent directory is a subdirectory of the source's parent directory.
3)  This code attempts to Normalize() the target file to deal with things like ".." in the
    filepath, because those could circumvent the check described in item #2.
4)  Normalize() fails with NS_ERROR_FILE_TARGET_DOES_NOT_EXIST and we consider
    the security check to have failed as a result.

So from the point of view of the worker code the load simply failed a same-origin load check, and hence is correctly reported as a SecurityError.  I don't see a simple way to make that same-origin check _pass_ in this case, because Normalize() just uses realpath() on non-Windows.  On Windows I expect the Normalize() succeeds, but then we perform a "is actually a file and not a directory" check anyway, and _that_ will fail for nonexistent files, because we just have no idea whether it is or not.

Given that, I think we should wontfix this; adding complexity to our security checks for this edge case doesn't seem worth it...

Comment 11

[Jukka Jylänki]

Thanks for the analysis Boris. Given that the error message nowadays does contain the filename, it is a big improvement over the previous blank "The operation is insecure." from the time of comment 0, so I'm ok to call this resolved (the original message was a head-scratcher). The NetworkError vs SecurityError doesn't have that much meaning on top of that.