JDK-4320895 : SocketPermision.implies broken when IP not accessible
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.3.0
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2000-03-11
  • Updated: 2000-03-14
  • Resolved: 2000-03-14
Related Reports
Duplicate :  
JDK-4321303 - SocketPermission doesn't work with trustProxy property.
Relates :  
JDK-4323955 - Rresource loading from a jar fails if hostname resolution fails
Description
he SocketPermision.implies call can sometimes return 'false'
when it should return true.

This happens if the hostname/IP address is not accessible. Calling
the implies multiple times (up to 3 times) and with trustedProxy=true,
will eventually get the right answer.

The bug has been observed in the following scenario:

1. Running an application in a sandbox and with proper proxy
   settings on the SWAN (using Jump).

2. The URLClassLoader is used to download jar files from an
   external website, e.g., www.swingteam.com

3. The URLClassLoader correctly downloads the jar file.

4. The application looks up an resource in the downloaded
   jar file, e.g., MainClass.class.getResource("arrow.gif").
 
   This should return a URL, such as: 

      jar:http://www.swingteam.com/apps/draw.jar!arrow.gif

5. The URLClassLoader.getResource will eventually call into
   SocketPermission.impliesIgnoreMask to check if:

   (java.net.SocketPermission www.swingteam.com connect,accept,resolve)

   implies:

   (java.net.SocketPermission www.swingteam.com:80 connect,resolve)  

   This should obviously be true. (We just downloaded a jar file from
   www.swingteam.com using the httpProxies).

6. The above check returns false, because the www.swingteam.com is outside 
   the firewall, so the name cannot be resolved. SocketPermission.getIP throws 
   an UnknownHostException

   As a cavecat:

   The getIP() address sets the SocketPermission to invalid if the call fails.
   Thus, if we call the implied a couple of times, then the first call will
   invalid the permissions, and the second will succeded if trustProxy=true.

   A stack trace is shown below of the failure.   

This bug is rather critical. This means that Jump cannot launch applications
downloaded from outside a firewall!  

The 1.2.x/1.3 AppletViewer should have the same problem! However, I have not 
confirmed that.

The fix seems to be rather simple, i.e, restructure the SocketPermission.impliesIgnoreMask to recheck if an UnknownHostException occures.

Stack trace
------------

java.net.UnknownHostException: www.swingteam.com
        at java.net.InetAddress.getAllByName0(InetAddress.java:577)
        at java.net.SocketPermission.getIP(SocketPermission.java:544)
        at java.net.SocketPermission.impliesIgnoreMask(SocketPermission.java:719)
        at java.net.SocketPermissionCollection.implies(SocketPermission.java:1074)
        at java.security.Permissions.implies(Permissions.java:134)
        at java.security.ProtectionDomain.implies(ProtectionDomain.java:92)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:180)
        at java.security.AccessController.checkPermission(AccessController.java:403)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at sun.misc.URLClassPath$Loader.check2(URLClassPath.java:422)
        at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:498)
        at sun.misc.URLClassPath.getResource(URLClassPath.java:133)
        at java.net.URLClassLoader.findResource(URLClassLoader.java:342)
        at java.lang.ClassLoader.getResource(ClassLoader.java:680)
        at com.sun.jnet.security.JNLPClassLoader.getResource(JNLPClassLoader.java:62)
        at java.lang.Class.getResource(Class.java:1194)
        at Draw.<init>(Draw.java:62)
        at Draw.main(Draw.java:555)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.sun.jnet.Launcher.executeApplication(Launcher.java:602)
        at com.sun.jnet.Launcher.executeMainClass(Launcher.java:489)
        at com.sun.jnet.Launcher.launchInThisVM(Launcher.java:357)
        at com.sun.jnet.Launcher.<init>(Launcher.java:77)
        at com.sun.jnet.Main.main(Main.java:150)


rene.schmidt@eng 2000-03-11
Comments
WORK AROUND The below workaround seems to do it for both 1.2.2 and 1.3rc2-w. (I did not work for 1.3rc1). Also, the work-around is only tested on one application. Create a subclass of URLClassLoader, and put in the following code for getResource: public URL getResource(String name) { // The below code is a workaround a bug in the SocketPermision.implied // code. If we are running behind a firewall, and the domain from where the // jar file is obtained from is not directly reachable (i.e. only reachable through // a proxyserver), the first timearound the SocketPermission will return false. The // second time around, the permission check will have degenerated into a textual // domain-name check (since we are running with -DtrustProxy=true), and therefor // will succeed. URL url = null; for(int i = 0; url == null && i < 3; i++) { if (Globals.TraceClassLoading) { Debug.println("Looking up resource: " + name + " (attempt: " + i + ")"); } url = super.getResource(name); } return url; }
11-06-2004
SUGGESTED FIX The fix seems to be rather simple, i.e, restructure the SocketPermission.impliesIgnoreMask to recheck if an UnknownHostException occures.
11-06-2004
EVALUATION This is a duplicate of 4321303 gary.ellison@eng 2000-03-14
14-03-2000