Summary

Permanently disable remote code downloading in JNDI

Problem

Remote code downloading in JNDI has been disabled by default since 8u121. Two system properties were introduced at that time to allow selectively reenable remote code downloading in JNDI/LDAP and JNDI/RMI. These two properties where never documented in the JDK itself, the only available documentation is in the release notes.

With the SecurityManager removed (see JEP 486), two system properties controlling remote code downloading in JNDI/LDAP and JNDI/RMI need to be removed: com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.ldap.object.trustURLCodebase.

Solution

Remove the com.sun.jndi.rmi.object.trustURLCodebase and the com.sun.jndi.ldap.object.trustURLCodebase system properties.

With both properties removed the remote code downloading is permanently disabled, unless a custom javax.naming.spi.ObjectFactoryBuilder is installed to implement a custom policy for loading object factories from the javax.naming.Reference or the javax.naming.Referenceable reference objects. For such scenarios a remote code downloading of an ObjectFactory class specified in a reference object fully depends on the policy determined by the installed ObjectFactoryBuilder.

The javax.naming.spi.NamingManager::getObjectInstance API documentation is updated to remove references to the SecurityManager and clarify that remote code downloading is not supported out of the box. A release note is planned to clarify that setting any of the two system properties com.sun.jndi.rmi.object.trustURLCodebase or com.sun.jndi.ldap.object.trustURLCodebase will have no effect.

Specification

src/java.naming/share/classes/javax/naming/spi/NamingManager.java:

@@ -123,9 +123,12 @@
      *    or {@code Referenceable} containing a factory class name,
      *    use the named factory to create the object.
      *    Return {@code refInfo} if the factory cannot be created.
-     *    Under JDK 1.1, if the factory class must be loaded from a location
-     *    specified in the reference, a {@code SecurityManager} must have
-     *    been installed or the factory creation will fail.
+     *    Downloading a factory class from a location specified in the reference
+     *    can be supported by a custom implementation of {@link ObjectFactoryBuilder}.
+     *    The {@linkplain Reference#getFactoryClassLocation() factory class
+     *    location}, if present, is ignored. A custom {@link ObjectFactoryBuilder}
+     *    {@linkplain #setObjectFactoryBuilder(ObjectFactoryBuilder) may be used}
+     *    if a different policy is desired.
      *    If an exception is encountered while creating the factory,
      *    it is passed up to the caller.
      * <li>If {@code refInfo} is a {@code Reference} or
      [....]
      */
      public static Object
          getObjectInstance(Object refInfo, Name name, Context nameCtx,
                            Hashtable<?,?> environment)
          throws Exception {

src/jdk.naming.rmi/share/classes/module-info.java:

An additional paragraph is added to the @implNote, to clarify the specific behaviour of our RegistryContext implementation:

@@ -58,6 +58,11 @@
  *          implementation.
  *     </li>
  * </ul>
+ * <p> Downloading a factory class from a {@linkplain javax.naming.Reference#getFactoryClassLocation()
+ * location} specified in the reference can be supported by a custom implementation of {@link
+ * javax.naming.spi.ObjectFactoryBuilder}. If a location is specified, then
+ * unless an {@link javax.naming.spi.ObjectFactoryBuilder} is installed a
+ * {@link javax.naming.ConfigurationException} is thrown.
  * @provides javax.naming.spi.InitialContextFactory
  * @moduleGraph
  * @since 9