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