db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2206) Provide complete security model for Java routines
Date Fri, 26 Jan 2007 19:28:49 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467891
] 

Rick Hillegas commented on DERBY-2206:
--------------------------------------

I don't have any client/server security holes in mind. Just reservations about how many knobs
we have.

Let's focus on java routine security, then. I think you're proposing that if a jar id turns
up in a routine's EXTERNAL NAME, then the SQL Standard prevails. Otherwise, the old rules
prevail--modulo your suggestion that, by default, derby.database.classpath is unset and this
prevents all user-published routines from running. We don't know how disruptive that last
point will be after upgrade.

Let me make sure that we're on the same page here:

WITH JAR ID

If an EXTERNAL NAME contains a jar id, then we check for USAGE privilege on that jar file
at DDL time. At run-time, the classpath is determined by SQLJ.ALTER_JAVA_PATH. USAGE privilege
is also checked when running SQLJ.ALTER_JAVA_PATH.

WITHOUT JAR ID

If an EXTERNAL NAME does not contain a jar id, then there's no USAGE privilege to check at
DDL time. At run-time, the classpath is determined by the old derby.database.classpath rules,
modulo your suggestion about the default derby.database.classpath state. I don't think we
need to require USAGE privilege in order to wire jar files into derby.database.classpath.
I think security here is managed fine by restricting the power to change 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
>
> 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.


Mime
View raw message