83864 - Access to Components.interfaces denied sometimes...

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[Johnny Stenback (:jst)]

When starting up mozilla/Netscape and typing javascript:Node.TEXT_NODE; we end
up getting a "Node is not defined" on the JS console, and if you type
javascript:Components.interfaces; in the URL bar you get an "Permission denied
to create wrapper for object" (which is what accessing Node.XXX does underneeth
the covers). Now, the interesting thing is that once you've run mozilla for a
while accessing Node.XXX works w/o problems, why, I have no idea.

I tracked down the problem when you start up mozilla and try to access
Components.interfaces and the problem goes away if I XPConnect allows creating a
wrapper for Components, this patch makes the problem go away:

Index: js/src/xpconnect/src/xpccomponents.cpp
===================================================================
RCS file: /cvsroot/mozilla/js/src/xpconnect/src/xpccomponents.cpp,v
retrieving revision 1.40
diff -u -r1.40 xpccomponents.cpp
--- xpccomponents.cpp   2001/05/23 00:12:04     1.40
+++ xpccomponents.cpp   2001/06/03 01:00:07
@@ -1762,8 +1762,8 @@
 NS_IMETHODIMP
 nsXPCComponents::CanCreateWrapper(const nsIID * iid, char **_retval)
 {
-    // If you have to ask, then the answer is NO
-    *_retval = nsnull;
+    // If you have to ask, then the answer is YES
+    *_retval = CloneAllAccess();
     return NS_OK;
 }

Interestingly enough, if I do:

  javascript:Components;

before trying either:

  javascript:Components.interfaces;

or

  javascript:Components.Node.ELEMENT_NODE;

I *don't* see this problem.

How is this possible? What should we do to fix this, apply my patch, or skip the
security checks when creating wrappers (as we've discussed before)? Or something
else? We need to get this solved for mozilla0.9.2.

Comment 1

[John Bandhauer]

Hmm. We create an initial wrapper when we attach the Components object to the 
window. The security check is bypassed then. But we also have to do the 
CanCreateWrapper check every time we build a tearoff - i.e. each time we QI the 
underlying native object to some particular interface. We'd have to do some real 
debugging to discover the source of the anomoly jst uncovered.

bug 79916 was masking the problem for a short while I expect. but that's been 
fixed for a few weeks now.

I don't really care if you go with jst's patch (and look into the other 
nsISecurityCheckedComponent::CanCreateWrapper cases for similar problems) or 
just decide to allow the creation of all wrappers in the security manager - 
that would be Mitch's decision.

Comment 2

[Mitchell Stoltz (not reading bugmail)]

I'm thinking about allowing all wrapper creation. jband tells me this was added
as belt-and-suspenders protection, and while it's good to have additional lines
of defense, this security check seems to be causing errors in a number of
unexpected places.

Let me throw out this question one last time, to whoever has an opinion on it:
If a script can create a wrapper for an object but can't call any methods or
access any properties on that wrapper, what can the script do with the wrapper?
What access is gained?

Comment 3

[John Bandhauer]

sr=jband on jst's patch. Even if you change the security manager to never call
this, it is a good change on its own.

Comment 4

[John Bandhauer]

Attachment: ensure wrapper creation allowed for nsJSIID too (includes jst's patch)

Comment 5

[David Bradley]

r=dbradley for the combined patch

Comment 6

[Johnny Stenback (:jst)]

sr=jst

Comment 7

[Mitchell Stoltz (not reading bugmail)]

The patch looks fine to me. r=mstoltz too.

Comment 8

[Christopher Blizzard (:blizzard)]

a=blizzard on behalf of drivers for the trunk

Comment 9

[David Bradley]

Patrick, I'm adding you since we'll have to do the checkin.

Comment 10

[Robert Ginda]

Checked in.

Comment 11

[Phil Schwartau]

Marking Verified Fixed. Using debug WinNT build 2001-06-19.
I can start up Mozilla from scratch, and access both 


javascript:Node.TEXT_NODE;        (= 3)

and 

javascript:Components.interfaces; (= [object nsXPCComponents_Interfaces])