JDK-6904882 : java.awt.Font.createFont() causes AccessControlException if executed with "-Djava.security.manager"
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2009-11-25
  • Updated: 2012-03-22
  • Resolved: 2010-07-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.
JDK 7
7Resolved
Related Reports
Duplicate :  
Relates :  
Description
JDK 7 b73 : PASSES
JDK 7 b74 : FAILS
Platform: Windows, Solaris

The following code minimized from JCK test that instantiates java.awt.Font from "A.ttf" file (attached to CR)
(IMPORTANT) executed with "-Djava.security.manager" option
---------------------------------------------------------------------------
import java.awt.*;
import java.io.File;
public class MiniTest {
    public static void main(String[] args) throws Exception {
        Font font = Font.createFont(Font.TRUETYPE_FONT, new File("A.ttf"));
    }
}
---------------------------------------------------------------------------

Fails with (on Windows):
Exception in thread "main" java.lang.ExceptionInInitializerError
        at sun.font.FontManagerFactory.<clinit>(FontManagerFactory.java:54)
        at java.awt.Font.<init>(Font.java:608)
        at java.awt.Font.createFont(Font.java:1018)
        at MiniTest.main(MiniTest.java:6)
Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "D:\devenv\jdk7b76\jre\lib\fonts\LucidaSansRegular.ttf" "read")
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:345)
        at java.security.AccessController.checkPermission(AccessController.java:555)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
        at java.io.File.exists(File.java:772)
        at sun.font.FontUtilities.<clinit>(FontUtilities.java:117)
        ... 4 more

Comments
EVALUATION Missing part of fix will be addressed as part of 6968373 (can not push new changeset using same bug id). This is in addition to changes made in b84.
12-07-2010

SUGGESTED FIX http://cr.openjdk.java.net/~rkennke/6904882/webrev.02/
07-02-2010

EVALUATION looks like another permission fallout from the refactoring. This line in the new FontUtilities class static initialiser used to be in a privileged context : isOpenJDK = !lucidaFile.exists(); Actually this about the only line of any consequence in that static initialiser that isn't in a doPrivilged. There are already 4 of them, this would be a 5th Given there's overhead to these I recommend just making it a single block for that class's initialiser.
25-11-2009

EVALUATION It is highly suspected that #6795908 is the root cause of this regression
25-11-2009