RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6]

[Alan Bateman]

On Sat, 2 Nov 2024 22:18:09 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Modify three RMI tests to work without the security manager:
>>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>>    Also remove them from the problem list.
>>  - Remove two obsolete RMI tests:
>>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>>    Adjust two tests to run without the Security Manager:
>>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>>    Remove all of these tests from the problem list.
>>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>>    grants no permissions. A few other small changes to Policy and PD.
>>  - Merge branch 'master' into jep486
>>  - JAXP tests: organize imports of a few tests
>>  - Improve description of Executors.privilegedThreadFactory
>>  - rename TestAppletLoggerContext.java as suggested in util test review
>>  - clientlibs: Javadoc cleanup
>>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b
>
> src/java.base/share/classes/java/lang/System.java line 2338:
> 
>> 2336:      * Invoked by VM.  Phase 3 is the final system initialization:
>> 2337:      * 1. eagerly initialize bootstrap method factories that might interact
>> 2338:      *    negatively with custom security managers and custom class loaders
> 
> They might still interact negatively with custom class loaders though.

The context here is custom a security manager doing string concatenation, this has required StringConcatFactory be eagerly initialized or security managers set on the command line to have been compiled with -XDstringConcat=inline. I think your question is about overriding the system class loader and whether its initialisation can use string concatenation reliably. That's a good thing to add a test for.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826916876