RFR: 8338536: Permanently disable remote code downloading in JNDI [v3]
Roger Riggs
rriggs at openjdk.org
Tue Nov 19 20:48:50 UTC 2024
On Tue, 19 Nov 2024 19:22:44 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:
>> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
>> - The following two properties are removed:
>> - `com.sun.jndi.ldap.object.trustURLCodebase`
>> - `com.sun.jndi.rmi.object.trustURLCodebase`
>> - JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
>> - The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
>> - Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.
>>
>> These changes require a CSR that will be submitted soon.
>>
>> ### Testing
>> - Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
>> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>
> clarify factory location usages in NamingManager and jdk.naming.rmi module-info
src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 262:
> 260: }
> 261:
> 262: worker = new Thread(this);
Rataining a static factory for thread may use useful to be able to customize thread behavior.
It should be considered that the new threads are Virtual threads:
i.e. `Thread.ofVirtual().startVirtualThread(Runnable)`
src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java line 163:
> 161: InputStream getJavaHomeConfStream(String filename) {
> 162: try {
> 163: String javahome = System.getProperty("java.home");
StaticProperty.javaHome() is available as a stable value for the property.
src/java.naming/share/classes/javax/naming/spi/NamingManager.java line 127:
> 125: * Return {@code refInfo} if the factory cannot be created.
> 126: * Downloading a factory class from a location specified in the reference
> 127: * is not supported out of the box.
"out of the box" seems a bit informal for the space.
Perhaps...
Downloading a factory class from a location specified in the reference can be supported by a custom implementation of {@link ObjectFactoryBuilder}.
etc.
src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java line 471:
> 469: /*
> 470: * Downloading a factory class from a location specified in the reference
> 471: * is not supported out of the box. A custom "ObjectFactoryBuilder"
Update here too for "out of the box" as above.
src/jdk.naming.rmi/share/classes/module-info.java line 61:
> 59: * </li>
> 60: * </ul>
> 61: * <p> Factory class names associated with a {@linkplain javax.naming.Reference#getFactoryClassLocation() factory
ditto
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1849021691
PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1849026408
PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1849030767
PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1849031705
PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1849032876
More information about the core-libs-dev
mailing list