RFR: 8341090: Remove support for security manager from JavaFX
Kevin Rushforth
kcr at openjdk.org
Wed Oct 9 14:53:36 UTC 2024
This PR removes support for running JavaFX applications with the Java Security Manager.
The initial work was done in 4 separate commits as follows:
* Fail fast at startup if the Security Manager is enabled
* Remove `-Djava.security.manager` and all security policy files; delete `SandboxAppTest`
* Delete remaining tests that depend on the Security Manager; as part of this, I renamed`CustomSecurityManagerTest` to `StageRobotTest` and removed all of the tests that depend on the security manager, since the test methods that don't depend on SM are useful functional tests of a Stage's FullScreen and AlwaysOnTop mode.
* API spec change to remove mention of security manager (including mention of throwing SecurityException)
This PR is both necessary and sufficient to remove support for running with the Java Security Manager enabled. I have tested this with JDK 23, which still has SM support (although deprecated for removal), and with a local JDK built from the [jdk-sandbox:jep486](https://github.com/openjdk/jdk-sandbox/tree/jep486) branch, which has the SM disabled. With both JDKs, I can build and run this PR branch; all tests pass. Attempting to enable the security manager with JDK 23 will now fail in `<clinit>` of either `LauncherImpl` (called by `Application.launch`) or `PlatformImpl` (called by `Platform.startup`) with an informative error message.
This PR should be integrated prior to the integration of JEP 486, so that we can continue to run JavaFX tests on JDK 24 after the SM is disabled. Otherwise they will fail to run with a fatal error launching the JVM (we currently pass `-Djava.security.manager=allow` when running our tests).
#### Follow-on work
I will file additional JBS issues to track follow-up work to cleanup the remaining calls to the security manager methods that are deprecated for removal. The follow-up work can be done independently of the timing of the integration of JEP 486 into JDK 24, but all of them will be targeted for JavaFX 24.
Follow-on issues for JavaFX 24:
* Remove all calls to `doPrivileged` (there are 350 such calls in 168 files)
* Remove all other calls to `AccessController` (48 calls in 33 files)
* Remove all remaining calls to `System::getSecurityManager` (45 calls in 27 files)
* Remove calls to deprecated SM methods from `PlatformUtil` and `MethodUtil` in `javafx.base` (these are lightly modified copies of those classes in `java.base` so I will check how they are being handled)
* Remove all uses (either throw or catch) of the deprecated `AccessControlException` : : 4 occurrences in 4 files
* Remove all occurrences where we throw a `SecurityException`; check all place where we catch it (and consider whether it is needed)
* Check and remove any remaining usages of other SM methods that are deprecated for removal by JEP 411
* SecurityManager 2 files (in addition to the ones that call `getSecurityManager`)
* AccessControlContext: 169 occurrences in 65 files (many are associated with doPriviliged calls, so should be rechecked once doPriv is removed)
* Utility method for fail fast SM check (if we keep the check, else remove it)
NOTE: I had earlier thought that the "fail fast" could be temporary until all follow-up work is done, but I now think we should leave it in for JavaFX 24, possibly adding it to two other classes -- `ReflectUtil` and `MethodUtil` -- depending on the follow-up work needed for those classes. If we do end up leaving it, I'll create a utility method in `javafx.base` that will use reflection to check whether the security manager is enabled, so we don't leave in a call to a method (`System::getSecurityManager`) that is deprecated for removal.
We might also file additional follow-up issues, not necessarily targeted for JavaFX 24:
* Consider deprecating for removal the following security-related APIs in JavaFX
* `FXPermission` (this PR changes the spec to make it clear that it is no longer used to control access to resources)
* `WebErrorEvent.USER_DATA_DIRECTORY_SECURITY_ERROR` (if there is no other use than to report a SecurityException that can no longer happen after the security manager is removed)
-------------
Commit messages:
- SM removal part 5: Update API spec to remove mention of security manager
- SM removal part 4: delete remaining tests that depend on security manager
- SM removal part 2: remove -Djava.security.manager and security policy files
- SM removal part 1: Fail fast at startup if the Security Manager is enabled
Changes: https://git.openjdk.org/jfx/pull/1595/files
Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1595&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8341090
Stats: 2163 lines in 45 files changed: 202 ins; 1948 del; 13 mod
Patch: https://git.openjdk.org/jfx/pull/1595.diff
Fetch: git fetch https://git.openjdk.org/jfx.git pull/1595/head:pull/1595
PR: https://git.openjdk.org/jfx/pull/1595
More information about the openjfx-dev
mailing list