RFR: 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation [v5]

[Daniel Fuchs]

On Fri, 14 Oct 2022 16:19:41 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>  - Remove factory builder synchronization from NamingManager. Update comments/docs.
>  - Change checkInput to be the global filter centric
>  - Refactor checkInput, better reporting for invalid filter patterns
>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>  - Additional comments/formatting cleanup.
>  - More tests clean-up. Code/doc comments cleanup.
>  - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
>  - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

src/java.base/share/conf/security/java.security line 1388:

> 1386: # are unused.
> 1387: #
> 1388: # Each class name pattern is matched against the factory class name to allow or disallow its

It appears that for those protocols for which there is no specific filter, a factory class will be accepted only if the global filter returns ALLOWED - which contradicts what is written here (where it says that the class is allowed if it's not REJECTED). Is this something that has changed with this fix - or was the documentation wrong before?

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

PR: https://git.openjdk.org/jdk/pull/10578