[
https://issues.apache.org/jira/browse/DERBY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467096
]
Rick Hillegas commented on DERBY-2206:
--------------------------------------
Dan wrote:
>How about really simple?
>derby.database.classpath - not set (default) - no user defined routines allowed
>derby.database.classpath= (empty string) - entry points in JRE classes allowed
>derby.database.classpath=valid path - entry points in JRE and listed jars
>allowed
OK, this is progress. Still puzzling to me, though: What is the upgrade story
here? In 10.2, under all of these settings of derby.database.classpath, you can
publish entry points both in the JRE and on the CLASSPATH.
>Some clarity on what "allowed" means is needed. Today when a routine is
>created there is no check that the class/method exists. That check is deferred
>to execution time of the routine. I haven't looked >to see what the SQL
>standard says for routines in terms of checking of if the jar, class and
>method exist at create time.
Here's my reading of section 9.8 (<SQL-invoked-routine>) of part 13 of the SQL
Standard:
Syntax Rule 9 seems to say that at creation-time, the jar file needs to contain
a class by the given name and inside that class (or its superclasses) there
needs to be a method by the given name. However, the signatures don't have to
match.
Syntax Rule 15 seems to say that it is implementation defined whether
signatures are matched at creation-time or execution-time.
Here is my reading of section 11.2 (SQLJ_REPLACE_JAR procedure) of part 13 of
the SQL Standard:
Syntax Rules 8 and 9 seem to say that an error is raised if the CREATE
PROCEDURE/FUNCTION statements cannot be replayed against the new jar file. That
is, whatever the creation-time rules are, they must still be valid after
replacing the jar file.
> 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.
-
You can reply to this email to add a comment to the issue online.
