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
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
- duplicates
-
JDK-4321303 SocketPermission doesn't work with trustProxy property.
- Resolved
- relates to
-
JDK-4323955 Rresource loading from a jar fails if hostname resolution fails
- Closed