JDK-4429806 : JWS 1.0 failed on Regression test case 4348803 (LB B20)
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 1.3.1
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_98
  • CPU: x86
  • Submitted: 2001-03-24
  • Updated: 2001-04-12
  • Resolved: 2001-04-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.0.1 1.0.1Fixed
Related Reports
Relates :  
Relates :  
Description
This bug was originally filed as 4420891. 4420891 was closed because 
initially we think it is a duplicate of bug 4416056. Now 4416056 bug
is verified and closed, but this bug still exists. So we are filing
it again.

The test case link is at:
http://comanche/jawstest/ladybird/regression

Step to reproduce the bug (On Windows):
- Install LB B20.
- Install JWS 1.0.
- Start JWS 1.0, from preference -> Java panel, make sure LB B20 is the only
  available JRE. Set logging and console for debugging in advance panel.
- Open browser and visit above link, follow the step 5 to reproduce the bug.

The exception message is:
java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)
        at java.security.AccessControlContext.checkPermission(Unknown Source)
        at java.security.AccessController.checkPermission(Unknown Source)
        at java.lang.SecurityManager.checkPermission(Unknown Source)
        at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
        at java.lang.System.getProperty(Unknown Source)
        at B4348803.extTest$1.run(extTest.java:27)
        at java.security.AccessController.doPrivileged(Native Method)
        at B4348803.extTest.run(extTest.java:23)
        at BUG4348803.run(BUG4348803.java:26)
        at BUG4348803.main(BUG4348803.java:21)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.sun.javaws.Launcher.executeApplication(Launcher.java:701)
        at com.sun.javaws.Launcher.executeMainClass(Launcher.java:663)
        at com.sun.javaws.Launcher.continueLaunch(Launcher.java:546)
        at com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java:334)
        at com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:151)
        at com.sun.javaws.Launcher.<init>(Launcher.java:113)
        at com.sun.javaws.Main.main(Main.java:153)

See more info in comments.

yu.wang@eng 2001-03-23

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.0.1 FIXED IN: 1.0.1 INTEGRATED IN: 1.0.1 VERIFIED IN: 1.0.1
31-08-2004

EVALUATION charlie.lai@Eng 2001-03-26 URLs are now encoded as of the latest changes to ladybird. this new bug is caused by the fact that inside of web start's AppPolicy implementation, a String comparison is done between a loaded extension class's codebase path (which is obtained via URL.getFile() and is encoded) and the extension directory path name (which is created once by hand and is not encoded). this comparison is done inside of the getPermissions method of AppPolicy. because one path is encoded and the other is not, the comparison will fail and AllPermission will not be granted to the extension class. charlie.lai@Eng 2001-03-29 just an extra note: JNLPClassPath and JNLPClassLoader inside of java web start both seem to have places where URLs need to be decoded and encoded when converting back and forth between file path names. ---------- We implemented fix in JNLPClassPath not to do URL.getFile() where there is a chance URL allready encoded. We don't do any encoding or decoding, but only use the url's as they were given to us. This seems to work for all test cases including this one andy.herrick@East 2001-04-05
05-04-2001