JDK-6983028 : java/awt/FontClass/FontPrivilege.java
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris,windows_xp
  • CPU: generic,x86
  • Submitted: 2010-09-08
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
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.
JDK 7
7 b126Fixed
Related Reports
Relates :  
CODETOOLS-7007304 - run main/othervm/secure=java.lang.SecurityManager causes false test failures
Relates :  
JDK-5010310 - Java2D font code opens font file outside of privileged block
Description
see comments
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/build/jdk/rev/99c540ac926c
17-01-2011
SUGGESTED FIX http://sa.sfbay.sun.com/projects/java2d_data/7/6983028/
02-11-2010
EVALUATION This problem seems to be caused by a bug in jtreg. Note that the regression test itself is not involved into stack trace reported here: for some reason, the jtreg code has no permission to access log file. To demonstrate this problem more clearly I have created simple test which always reports success and run it in following ways: a) @run main/othervm SimpleSecurityTest b) @run main/othervm/secure=java.lang.SecurityManager/policy=security.policy SimpleSecurityTest c) @run main/othervm/secure=java.lang.SecurityManager SimpleSecurityTest Ways a) and b) work fine, but c) always fails due to lack of permissions: Exception in thread "main" java.security.AccessControlException: access denied ( java.io.FilePermission C:\work\jdk_ws\2d.fixes\jdk\test\JTwork\classes\java\awt\SimpleSecurityTest.jta read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.FileInputStream.<init>(FileInputStream.java:100) at java.io.FileInputStream.<init>(FileInputStream.java:66) at java.io.FileReader.<init>(FileReader.java:41) at com.sun.javatest.regtest.MainWrapper.main(MainWrapper.java:45) Note that c) if perfectly legal from the spec point of view according to tag-spec.txt: /secure=<class> Specify a subclass of java.lang.SecurityManager to be installed as the security manager. An appropriate @build tag should be provided to ensure that the class is compiled. If the /secure option is used without the /policy option then the system's built-in policy, equivalent to the original sandbox policy, will be assumed. So, this problem should be resolved on jtreg side. However, to prevent the test failure, I suggest to workaround in by installation of security manager explicitly in the test.
02-11-2010