[
https://issues.apache.org/jira/browse/DERBY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466755
]
Daniel John Debrunner commented on DERBY-2206:
----------------------------------------------
Rick wrote:
--------
What's puzzling me right now is how to secure routines without requiring jar
ids. Suppose that we do not have the SYS.ENV pseudo-jar and we let users
declare routines without qualifying them with jar ids. What prevents users from
publishing entry points in the JRE or on the system CLASSPATH?
--------
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
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.
> 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.
