[
https://issues.apache.org/jira/browse/DERBY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466434
]
Kristian Waagan commented on DERBY-2206:
----------------------------------------
You might already be aware of this, but you can change which classes are loaded
by the bootstrap classloader by using one of the -Xbootclasspath options. In a
trusted environment you can probably use the classloader == null check to
determine if a class is a "JRE class", but in general any class can be a "JRE
class".
I also confirmed that both IBM and BEA VMs use null for the bootstrap
classloader, but as Dan points out, I don't think this can be guaranteed. It
also seems like these two vendors use the Sun application classloader
(sun.misc.Launcher$AppClassLoader), but if it really is Sun's implementation I
don't know.
I think Dan's suggestion about combining the two categories of classes makes
sense, if it goes well with the security model being worked out.
> 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
