JDK-8097371 : [JFXPanel] SecurityException in PlatformUtil when running SwingInterop with security manager
  • Type: Bug
  • Component: javafx
  • Sub-Component: application-lifecycle
  • Affected Version: 8
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-03-11
  • Updated: 2015-06-12
  • Resolved: 2014-03-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 8
8u20Fixed
Related Reports
Relates :  
Relates :  
Sub Tasks
JDK-8097532 :  
Description
To reproduce the bug, run the SwingInterop example program, or any other JFXPanel app, such as HelloJFXPanel, with a security manager enabled (or run it as an untrusted applet or Web Start app). For example:

$ java -Djava.security.manager helloworld.HelloJFXPanel

Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
	at com.sun.javafx.tk.Toolkit.getDefaultToolkit(Toolkit.java:118)
	at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:166)
	at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:214)
	at javafx.embed.swing.JFXPanel.initFx(JFXPanel.java:198)
	at javafx.embed.swing.JFXPanel.<init>(JFXPanel.java:213)
	at helloworld.HelloJFXPanel.<init>(HelloJFXPanel.java:53)
	at helloworld.HelloJFXPanel$3.run(HelloJFXPanel.java:102)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744)
	at java.awt.EventQueue.access$400(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:697)
	at java.awt.EventQueue$3.run(EventQueue.java:691)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:714)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "javafx.platform" "read")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457)
	at java.security.AccessController.checkPermission(AccessController.java:884)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294)
	at java.lang.System.getProperty(System.java:714)
	at com.sun.javafx.PlatformUtil.<clinit>(PlatformUtil.java:63)
	... 21 more

Comments
Unit Test: tests/system/src/test/java/sandbox/SandboxAppTest.java
19-03-2014

I am requesting to take this fix into 8u11 for CPU14_03. Justification: This is a regression introduced in JDK 8. Without this fix, all Swing applets or Web Start apps that run in a sandbox and use JFXPanel fail at startup. For applets, there is no known workaround other than to request all permissions. Risk: very low. It is a one line change that avoids the offending call to System.getProperty outside a doPrivileged block.
12-03-2014

http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/5ccfbb1bbdad
12-03-2014

To verify this fix, run an untrusted version of the SwingInterop applet. A unit test is not feasible, since it requires a complete FX runtime and requires that it be run as part of the security manager. I plan to write an automated regression test for this as part of RT-36197, so that we don't have to rely on manually verification it for each release.
12-03-2014

I will add the following comment: // NOTE: since this class can be initialized by application code in some // cases, we must encapsulate all calls to System.getProperty("...") in // a doPrivileged block except for standard JVM properties such as // os.name, os.version, os.arch, java.vm.name, etc.
12-03-2014

+1 Had a discussion with Kevin about the fact that normally, the first condition is false and that the second condition runs. It also asks for a property but this is a well known one that won't trigger security. I suggest that Kevin add a comment that the doPriv() is not needed. Personally, I feel that we should surround all getProperty() things with a doPriv() all the time. Very often someone will come along later and if they don't see the doPriv(), they will make the mistake. Further, the list of properties that are ok and ones that trigger security needs to be remembered by the programmer. Basically, getProperty() is a disaster waiting to happen.
12-03-2014

Looks good to me. Thanks!
12-03-2014

Please review the following: http://cr.openjdk.java.net/~kcr/RT-36189/ Reviewers: snorthov, ngthomas This is a simple fix to replace reading the System property with a static variable into which the property has already been read.
12-03-2014

Note that this blocks execution of the existing SwingInterop sample on OTN from running on JDK8. http://www.oracle.com/technetwork/java/javafx/samples/index.html A workaround is in progress, but this will similarly prevent any Swing app using JFXPanel from running in a browser or as a JNLP app unless the app requests elevated privileges.
12-03-2014

This is a regression from FX 2, caused by the following line in PlatformUtil.java: private static final boolean ANDROID = "android".equals(System.getProperty("javafx.platform")) ... All reads of properties in PlatformUtil except this one are done in a doPrivileged. In this case, the property has already been read (and/or loaded from a property file), so the fix is just to use the existing javafxPlatform variable instead of reading the system property again.
12-03-2014