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