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

[Roger Riggs]

On Wed, 5 Oct 2022 15:23:43 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.

Nice work, but a few comments.

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 91:

> 89:     }
> 90: 
> 91:     private static boolean checkInput(String scheme, FactoryInfo factoryInfo) {

This construct in which the supplied lambda fills in the serialClass is pretty obscure. 
Perhaps the variable name can be "serialClass" to match the only non-default method in ObjectInputFilter would give a better hint.

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 92:

> 90: 
> 91:     private static boolean checkInput(String scheme, FactoryInfo factoryInfo) {
> 92:         Status result = switch(scheme) {

The handling of the selection of the filter could be more direct.
You can change the argument to checkInput to be ObjectInputFilter and pass the desired filter; LDAP_FILTER, RMI_FITLER, or GLOBAL_FILTER.
And make the check of the GLOBAL_FILTER conditional on it not having already been evaluated.
Then it will be the case that there must always be a specific filter.

The callers are all local to the class and would change to pass the desired filter.

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 173:

> 171:                                            DEFAULT_GLOBAL_SP_VALUE));
> 172: 
> 173:     // A system-wide LDAP specific object factories filter constructed from the system

Where does the IllegalArgumentException from ObjectInputFilter.create get handled or reported?
If the property value is illformed, the error should be enough to diagnose and correct the property.

test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java line 46:

> 44:  * @build LDAPServer LDAPTestUtils TestFactory
> 45:  *
> 46:  * @run main/othervm LdapFactoriesFilterTest false

Are any of these filter property cases, malformed and would produce an error from ObjectInputFilter.create?

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

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