On Tue, 19 Nov 2024 19:22:44 GMT, Aleksei Efimov <aefi...@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
