Privileges granted to a page do not extend to event listeners in the page

RESOLVED INVALID

Status

()

--
major
RESOLVED INVALID
11 years ago
11 years ago

People

(Reporter: WeirdAl, Assigned: dveditz)

Tracking

({testcase})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
Created attachment 282779 [details]
test page

When I have an event listener in a HTML page, and the HTML page has received UniversalXPConnect privileges, I would expect the page's event listeners to have the same privileges.  Instead, I find that CAPS rejects privileges for the event listener which the page itself has.

Steps to reproduce:
(1) Save the test page to your local drive.
(2) Examine the page in your text editor to be sure it does nothing dangerous.  (In this case, all it tries to do is create a transaction manager.)
(3) Open the local copy of the attachment.
(4) You should get a permissions dialog; tell the browser to grant privileges.
(5) You should see an alert saying "configTest: true".  Dismiss it.

Expected results:
The page says "This test has passed."

Actual results:
An alert appears stating "Permission denied to get property XPComponents.classes".  The page says "This test has not passed."

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092409 Minefield/3.0a9pre

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/2007091417 Firefox/2.0.0.7

Attempts to work around this bug using window.setInterval() were also unsuccessful.

This bug is causing problems for a product my company (DVC Labs) is developing.
Flags: blocking1.9?
This is a long-standing an well known bug, I think. enablePrivilege calls only apply to the current JS stack frame.
The "page" does not receive any privileges, privileges are enabled for the lifetime of the function in which they are granted. When your top-level function exits the privileges are reverted. When the even handler fires the function with the enabled privilege is no longer on the stack.

You need to ask for permission inside the event block. This is not a bug.

The fact that the user will have to grant them repeatedly is a missing feature. The idea is that you raise your abilities for the least amount of time necessary to limit exposure to mistakes and hacking (like using *nix "su"). In Java the granting of the permission was remembered for the life of the applet (if not granted permanently), so the applet could enable and disable super-powers as needed. Javascript has no applet to hang temporary permissions on, and if we really cared about capabilities and signed javascript (we don't) we would need to do something like this to make things work. Maybe we could hang this on the page principal...
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
(Reporter)

Comment 3

11 years ago
dveditz: There's just one little problem:  my test page doesn't grant the privileges within a top-level function, but as part of a script that defines the inner function simultaneously.  Unless I'm totally misinterpreting what you're saying and JS scope has absolutely nothing to do with this...

Removing blocking request; invalid bugs can't block 1.9.
Flags: blocking1.9?
Yes, the top-level script creates the inner function but it does not *call* it. Capabilities are checked by walking up the frame stack, and when the event handler is executed nowhere on the stack will it find your top-level script with the enablePrivilege annotation.

I'm not saying it doesn't suck, just describing the way it works. "Fixing" it requires rearchitecting caps which is less likely than killing capabilties altogether.
You need to log in before you can comment on or make changes to this bug.