# Re: Loading Security Provider Classes via ClassLoader

Roland Schemers (Roland.Schemers@Eng)
Tue, 28 Apr 1998 12:24:34 -0800 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Roland Schemers: "Re: Loading Security Provider Classes via ClassLoader"
- Previous message: David Brownell: "Re: Certification Authority"
- In reply to: Vishal Goenka: "Loading Security Provider Classes via ClassLoader"
- Next in thread: Roland Schemers: "Re: Loading Security Provider Classes via ClassLoader"

    From: Roland.Schemers@Eng (Roland Schemers)

    Message-Id: <199804281924.MAA08604@crypto.eng.sun.com>

    Subject: Re: Loading Security Provider Classes via ClassLoader

    To: vgoenka@novell.com (Vishal Goenka)

    Date: Tue, 28 Apr 1998 12:24:34 -0800 (PDT)

    In-Reply-To: <s5458514.052@novell.com> from "Vishal Goenka" at Apr 28, 98 07:27:41 am

>
> The getInstance(algorithm, provider) method of various security algorithms =
> (MessageDigest et.al.) invoke the Security.getImpl(...) method, which in =
> turn instantiates the required class (after mapping the actual implementati=
> on class name via the security provider) using Class.forName(className), =
> where className is the implementation class that we require to load.
>
> If the implementation class ("className") is not available in the class =
> path, but is accessible only through my own classloader (say), the =
> Class.forName method returns error (obviously).

This is correct. This is indeed a problem in JDK 1.1.x which we have fixed
in JDK 1.2. The problem is exactly as you describe it. Since the internal
getImpl call uses string names and calls Class.forName, the only class loader
that is searched is the system class loader. That is because Class.forName
always uses the class loader of the caller.

The solution is to do something like the following instead of simply doing
Class.forName:

ClassLoader cl = provider.getClassLoader();
if (cl != null)
provider.getClassLoader().loadClass(className);
else
Class.forName(className);

i.e., use the same class loader as the provider that has the
implementation.

We'll have to see if it is possible to fix this in JDK 1.1.7 or
not. I think it should be safe to fix, as if there is a security manager
installed then only trusted people can dynamically add a provider.

thanks, roland

- Next message: Roland Schemers: "Re: Loading Security Provider Classes via ClassLoader"
- Previous message: David Brownell: "Re: Certification Authority"
- In reply to: Vishal Goenka: "Loading Security Provider Classes via ClassLoader"
- Next in thread: Roland Schemers: "Re: Loading Security Provider Classes via ClassLoader"