[
https://issues.apache.org/jira/browse/DERBY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465623
]
Daniel John Debrunner commented on DERBY-2206:
----------------------------------------------
> Rick Hillegas commented on DERBY-2206:
> --------------------------------------
>
> I have some questions about the wiki page:
Thanks for reading & providing feedback.
> I think this analysis assumes that the engine is running under a
> SecurityManager with some Basic policy (defined elsewhere). So, for instance,
> user code is not allowed to create a custom classloader that can load classes
> from just about anywhere, including from the file which holds the jars
> installed into SYSFILES. Without this assumption, I think we may need to
> revisit some of the entries in the Referenced Classes sections. Maybe the
> Assumptions section could be pulled up to the top of the wiki page.
I thought that the assumptions only applied to discussion that followed that
section. Before the assumptions section it's definitions of how classes could
be loaded, not which are possible. Maybe there needs to be another category of
class defined, those from a class loader created by a referenced class.
> "Resolving Classes -> 2nd Entry Point Class":
>
> I'm confused about why the Visibility is different for DBCP and SQLJAR.
> Wouldn't the USAGE privilege control the visibility of jar files stored in
> the database regardless of whether they appear on derby.database.classpath?
If you mean the section when the routine has an EXTERNAL NAME with a jarid,
then the database class path (DBCP) is not applicable. The class loading is
defined by the SQL standard which only loads from the jar the entry point class
is in and the classpath for that jar file (if set).
> Following Referenced Classes section:
>
> This sentence ends abruptly: "The installed jar's optional classpath is."
fixed
>
> "Setting derby.database.classpath":
>
> As I read section 4.3 of the SQL Standard, part 13, the order of resolution
> for classes referenced inside a loaded jar file looks like this:
>
> 1) First look for the class in that jar file
> 2) Then look for the class in the JAVA_PATH bound to that jar file
>
> So the second bullet is true only if the jar file leads the list in
> derby.database.classpath.
I don't see your logic here. If I have
derby.database.classpath="ONE:TWO:THREE"
then if my routine's entry point is in the THREE jar then referenced classes
can be any class from ONE, TWO or THREE, which is as though the THREE jar had
the classpath "ONE:TWO:THREE".
So I can't see what is special about the first class specified in
derby.database.classpath.
> 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
