Access to Components.interfaces denied sometimes...

VERIFIED FIXED in mozilla0.9.2

Status

()

Core
XPConnect
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: jst, Assigned: David Bradley)

Tracking

({regression})

Trunk
mozilla0.9.2
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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.
(Reporter)

Updated

17 years ago
Keywords: mozilla0.9.2, regression

Comment 1

17 years ago
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.
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

17 years ago
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

17 years ago
Created attachment 37119 [details] [diff] [review]
ensure wrapper creation allowed for nsJSIID too (includes jst's patch)
(Assignee)

Comment 5

17 years ago
r=dbradley for the combined patch
Status: NEW → ASSIGNED
(Reporter)

Comment 6

17 years ago
sr=jst
(Assignee)

Updated

17 years ago
Keywords: approval
The patch looks fine to me. r=mstoltz too.
(Assignee)

Updated

17 years ago
Target Milestone: --- → mozilla0.9.2

Updated

17 years ago
Blocks: 83989
a=blizzard on behalf of drivers for the trunk
(Assignee)

Comment 9

17 years ago
Patrick, I'm adding you since we'll have to do the checkin.
(Assignee)

Updated

17 years ago
Whiteboard: approved

Comment 10

17 years ago
Checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Whiteboard: approved

Comment 11

17 years ago
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])
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.