JDK-8160768: LdapDnsProviderService confined to application class loader

Osipov, Michael michael.osipov at siemens.com
Fri Apr 17 09:10:43 UTC 2020


Am 2020-04-17 um 09:22 schrieb Alan Bateman:
> On 16/04/2020 11:05, Osipov, Michael wrote:
>>
>> That's exactly the point. I don't want to bundle it with the webapp, 
>> but with Tomcat only for all webapps. It will be added to 
>> CATALINA_HOME/lib along with a custom realm. Both are loaded with 
>> Tomcat's common.loader [1]. No, it does not load from common.loader 
>> because of the system class loader restriction. It only works when it 
>> is loaded along side with catalina.jar from the system class loader 
>> (as intended).
> I don't have time to spend on the spec and security implications of what 
> you are requesting but it seems like this should be easily fixable by 
> deploying the DNS provider for LDAP searches on the class path (along 
> side catalina.jar). So is this mostly just a convenience issue, meaning 
> easier to drop the JAR file in the lib directory vs. adding it to 
> CLASSPAHTH?

After a quick investigation, I think I slightly understand the security 
implications you have mentioned. You don't want to load additional 
instances in the base system from untrusted sources. This makes sense.

As for the convenience: Yes, somewhat. You have to actively (explicitly) 
modify Tomcat's CLASSPATH; either in setenv.sh or with Commons Daemon 
args. Eveything in lib/ will be automatically loaded via common.loader= 
.../lib/*.jar; drop and go.

Michael


More information about the core-libs-dev mailing list