You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Hillegas (JIRA)" <ji...@apache.org> on 2007/01/17 19:34:30 UTC

[jira] Commented: (DERBY-2206) Provide complete security model for Java routines

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

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

I have some questions about the wiki page:

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.

"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?

Following Referenced Classes section:

This sentence ends abruptly: "The installed jar's optional classpath is."

"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.





> 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