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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
