JDK-8200082 : Need to restrict access to FX packages when loaded by AppClassLoader
  • Type: Bug
  • Component: javafx
  • Sub-Component: other
  • Affected Version: jfx11
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2018-03-21
  • Updated: 2024-10-18
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
tbdUnresolved
Related Reports
Relates :  
JDK-8195800 - Eliminate dependency on sun.reflect.misc in javafx modules
Relates :  
JDK-8341090 - Remove support for security manager from JavaFX
Description
The SecurityManager check that restricts internal packages will only restrict those packages that are part of the platform. Packages loaded by the AppClassLoader are not subject to this restriction. Once the javafx modules are removed from the JDK, applications will load them using the AppClassLoader. This means that the calls to ReflectUtil::checkPackageAccess will no longer block access to such packages when a security manager is present. If this check is still needed, then we need to look for an alternate solution.
Comments
The security manager will be deprecated for removal in JDK 17 as part of JEP 411, JDK-8264713. If we decide to address this bug in a future release, it should be recast as an issue of encapsulation, which is equally valid regardless of whether or not an application is using the security manager.
15-04-2021
Lowering to P3 based on the above evaluation.
24-08-2018
JavaFX is now loaded by the application class loader, and no longer has privileges by default. This bug will only affect applications that explicitly enable a security manager and use a custom security policy file to grant privileges to the javafx.* modules, without granting those same privileges to their application. Even in such cases, the only thing that could happen is that a sandboxed application running in such a mode, might be able to access internal JavaFX classes in some situations, so the impact is limited. Retargeting to openjfx12.
24-08-2018
This is only an issue for framework code such as FXML or JavaFX Beans that accesses classes on behalf of applications. Direct access by applications is denied by the encapsulation provided by the module system, irrespective of whether a security manager is present.
23-03-2018