EVALUATION
In 6u24, when we fix the bug:
6954743 "Applet codebase parameter permits web to file system linking"
We introduced a method called checkTargetURL to perform the security check, based on permission objects obtained from URLConnection. (via URL.openConnection)
Problem is in the case where custom HTTP handler is installed, we might ran into ClassCircularityError. For example:
1) Application registers new HttpURLConnectionHandler
It is supposed to be called by URL.openConnection()
Note that registration is just specifying the property => no classes are loaded
2) user code wants to load something from remote jar
3) this initiate checkURL and this will require http connection => lead to attempt to load some user class from connection handler
4) handler itself (or its dependency) is needs to loaded from remote jar => checkURL is called again and will try to do openConnection again
5) this means attempt to resolve handler class again (like on step 4) => classloader detects circularity
|
EVALUATION
customer provided testcase that can be used to reproduce the bug:
http://javaweb.sfbay.sun.com/~ngthomas/filemaker/httptest.jnlp
also evaluation from networking team:
The stacktrace (see the last stacktrace below, original from the customer) shows that URLUtil.checkTargetURL() may lead to a HTTP connection which leads to the problem. That is,
1) Try to load a class
2) findClass may trigger the HTTP connection
3) DeployURLClassPath$JarLoader.checkResource invokes checkTargetURL()
4) May trigger a HTTP connection
5) DeployURLClassPath$JarLoader.checkResource invokes checkTargetURL()
6) Bang!
I think this may be a general problem with the original fix for CR 6954743. You may need to ensure that circularity cannot occur.
This issue may be specific to when a user defined HTTP protocol handler is installed. A user defined protocol handler may force the loading of classes/resources from the codebase, i.e. not on the classpath. Hence the circularity problem. But I think this code needs to be carefully reexamined.
|
Java