RE: Moving system properties to gnu.classpath.*

[Jeroen Frijters]

David Holmes wrote:
> At present there is only one classloader that documents that it will
> do a package access check, and that is the classloader returned by
> URLClassLoader.newInstance.

According to the table in the TechTips article, the system class loader
also does the check (and that's the place that makes the most sense to
me).

> http://java.sun.com/developer/JDCTechTips/2001/tt0130.html

Thanks for this link, this article explains a lot.

> Now I don't see anything that says that the 
> system/application classloader, or even the bootstrap loader
> couldn't perform this check - but I'm not sure
> it would be such a good idea, or help that much.

I think that a check in the system class loader would work and be
sufficient to protect access to our "private" package.

> The question is: what were we trying to protect and under 
> what conditions?

Here is my scenario:
- I want to eliminate dependency cycles in the core classes as much as
possible.
- I don't want to use AccessController.doPrivileged or reflection (for
hopefully obvious reasons).
- To do the above I suggested we create a special package that is not
accessible from untrusted code (i.e. set the security property
"package.access" to e.g. "gnu.classpath.", then we can have public
classes in the gnu.classpath package that can be used from within
Classpath (i.e. all code loaded by the bootstrap class loader), but
cannot be accessed by code loaded with the system class loader (or any
other class loader, for that matter).
- If there is no SecurityManager, anyone can access the "private"
package (this is equivalent to the current situation, because currently
you can use reflection to get at the internals).

> As I understand it the intent was to have a public class with 
> public methods that was meant to be inaccessible to anything not
> loaded by the bootstrap loader.

Exactly.

> That would imply making the system classloader implement this
> check.
> However, such a check would only occur when a security 
> manager is installed anyway, so what exactly are we trying to
> protect here?

The public classes in the "private" package expose priviliged
operations, without doing any security checks (instead relying on the
fact that the package is "private").

Regards,
Jeroen