Bug 620733 - java.security.AccessControlException when calling privileged Java methods from chrome. r=bz,jst a2.0=jst
authorSteven Michaud <smichaud@pobox.com>
Tue, 11 Jan 2011 10:00:36 -0600
changeset 60297 f8330dec502bfaecb597405c9a670cd887ffcdb7
parent 60296 0294914a8a4599a7ed30bbc35edf53784c29e9d1
child 60298 7a5beb46743f7f0811e5551d93c7a49c1ca739b5
push idunknown
push userunknown
push dateunknown
reviewersbz, jst
bugs620733
milestone2.0b10pre
Bug 620733 - java.security.AccessControlException when calling privileged Java methods from chrome. r=bz,jst a2.0=jst
netwerk/base/public/nsNetUtil.h
--- a/netwerk/base/public/nsNetUtil.h
+++ b/netwerk/base/public/nsNetUtil.h
@@ -1832,17 +1832,18 @@ NS_MakeRandomInvalidURLString(nsCString&
 }
 #undef NS_FAKE_SCHEME
 #undef NS_FAKE_TLD
 
 /**
  * Helper function to determine whether urlString is Java-compatible --
  * whether it can be passed to the Java URL(String) constructor without the
  * latter throwing a MalformedURLException, or without Java otherwise
- * mishandling it.
+ * mishandling it.  This function (in effect) implements a scheme whitelist
+ * for Java.
  */  
 inline nsresult
 NS_CheckIsJavaCompatibleURLString(nsCString& urlString, PRBool *result)
 {
   *result = PR_FALSE; // Default to "no"
 
   nsresult rv = NS_OK;
   nsCOMPtr<nsIURLParser> urlParser =
@@ -1854,26 +1855,44 @@ NS_CheckIsJavaCompatibleURLString(nsCStr
   PRUint32 schemePos = 0;
   PRInt32 schemeLen = 0;
   urlParser->ParseURL(urlString.get(), -1, &schemePos, &schemeLen,
                       nsnull, nsnull, nsnull, nsnull);
   if (schemeLen != -1) {
     nsCString scheme;
     scheme.Assign(urlString.get() + schemePos, schemeLen);
     // By default Java only understands a small number of URL schemes, and of
-    // these only some are likely to represent user input (for example from a
-    // link or the location bar) that Java can legitimately be expected to
-    // handle.  (Besides those listed below, Java also understands the "jar",
-    // "mailto" and "netdoc" schemes.  But it probably doesn't expect these
-    // from a browser, and is therefore likely to mishandle them.)
+    // these only some can legitimately represent a browser page's "origin"
+    // (and be something we can legitimately expect Java to handle ... or not
+    // to mishandle).
+    //
+    // Besides those listed below, the OJI plugin understands the "jar",
+    // "mailto", "netdoc", "javascript" and "rmi" schemes, and Java Plugin2
+    // also understands the "about" scheme.  We actually pass "about" URLs
+    // to Java ("about:blank" when processing a javascript: URL (one that
+    // calls Java) from the location bar of a blank page, and (in FF4 and up)
+    // "about:home" when processing a javascript: URL from the home page).
+    // And Java doesn't appear to mishandle them (for example it doesn't allow
+    // connections to "about" URLs).  But it doesn't make any sense to do
+    // same-origin checks on "about" URLs, so we don't include them in our
+    // scheme whitelist.
+    //
+    // The OJI plugin doesn't understand "chrome" URLs (only Java Plugin2
+    // does) -- so we mustn't pass them to the OJI plugin.  But we do need to
+    // pass "chrome" URLs to Java Plugin2:  Java Plugin2 grants additional
+    // privileges to chrome "origins", and some extensions take advantage of
+    // this.  For more information see bug 620773.
+    //
+    // As of FF4, we no longer support the OJI plugin.
     if (PL_strcasecmp(scheme.get(), "http") &&
         PL_strcasecmp(scheme.get(), "https") &&
         PL_strcasecmp(scheme.get(), "file") &&
         PL_strcasecmp(scheme.get(), "ftp") &&
-        PL_strcasecmp(scheme.get(), "gopher"))
+        PL_strcasecmp(scheme.get(), "gopher") &&
+        PL_strcasecmp(scheme.get(), "chrome"))
       compatible = PR_FALSE;
   } else {
     compatible = PR_FALSE;
   }
 
   *result = compatible;
 
   return NS_OK;