[
https://issues.apache.org/jira/browse/DERBY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466190
]
Rick Hillegas commented on DERBY-2206:
--------------------------------------
Thanks for those pointers. I have run a couple experiments on the Sun 1.4, 1.5,
and 1.6 solaris vms. I get identical results on all vms. Here are those results:
By default, I have three classloaders:
1) A sun.misc.Launcher$AppClassLoader. This is the classloader returned by
ClassLoader.getSystemClassLoader(). It is the ClassLoader which loads classes
which I have written. I believe that this ClassLoader is responsible for
classes visible on the CLASSPATH. I'm going to call this the System classloader.
2) That ClassLoader has a parent, which is a sun.misc.Launcher$ExtClassLoader.
This parent ClassLoader seems to be responsible for loading classes from jar
files in jre/lib/ext. I'm going to call this the Extensions classloader.
3) That ClassLoader has a null parent. I sampled some classes which appear in
the javadoc for the Sun JREs. All of the the sampled classes have null as their
ClassLoader. This includes classes in java.*, javax.*, org.w3c.dom.*, etc. I
think that this null represents the JRE's ClassLoader.
In trying to map this onto the concepts on the wiki page, I come up with
something like the following:
A) SYS.CLASSPATH embraces all classes whose ClassLoader is the System
classloader. At a minimum.
B) I don't know where to fit the classes loaded by the Extensions classloader.
C) SYS.JRE could embrace all classes whose ClassLoader is null. I don't know
whether the UR classloader is represented as null by other VM vendors. I also
don't know if other vendors manage the same set of classes with their UR
classloaders. I am worried about defining SYS.JRE as just the classes in
java.*. I think that it would be prudent to respect the VM vendor's judgment
about which classes cohere together under the UR classloader.
> Provide complete security model for Java routines
> -------------------------------------------------
>
> Key: DERBY-2206
> URL: https://issues.apache.org/jira/browse/DERBY-2206
> Project: Derby
> Issue Type: New Feature
> Components: Security, SQL
> Reporter: Rick Hillegas
> Fix For: 10.3.0.0
>
>
> Add GRANT/REVOKE mechanisms to control which jar files can be mined for
> user-created objects such as Functions and Procedures. In the future this may
> include Aggregates and Function Tables also. The issues are summarized on the
> following wiki page: http://wiki.apache.org/db-derby/JavaRoutineSecurity.
> Plugin management can be tracked by this JIRA rather than by DERBY-2109. This
> is a master JIRA to which subtasks can be linked.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
