db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Satheesh Bandaram (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network configurations.
Date Thu, 16 Feb 2006 22:46:00 GMT
    [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12366700 ] 

Satheesh Bandaram commented on DERBY-464:
-----------------------------------------

Thanks for your comments, Dan. I will update the spec, but some answers below:

"This property could be set either as a system property in derby.properties file or as application
property." This needs re-wording, system properties are set as JVM system proiperties, application
properties is what is used to describe properties in derby.properties. You could just say
'this is a standard Derby property" 

OK... Tuning guide refers to both as System-wide properties... System-wide properties set
programmatically and System-wide properties set in derby.properties. 

- The design doesn't contain any mention of modifications to the statement dependencies. It
may be (after thinking about it for 10 seconds) that any grant/revoke statement does not need
to invalidate any DML compiled statements. It would be good to state this and the reasons
why. 

Right... Grant and Revoke statements don't need to invalidate any existing compiled statements.
This is because the compiled plan doesn't assume if any permissions are granted or not...
Compilation only notes required object accesses to execute a statement. Only at runtime, these
checks are performed. I will add more info to design section.

- I couldn't see where you are storing the owner of the database

Any ideas where it could be? :) I haven't coded that part. I was thinking of using an internal
property to store the database owner. Are there any internal use only properties in Derby
currently? I thought boot password is kind of stored like this?

- Can you expand on the design around the StatementPermission class and its sub-classes. Which
methods are invovled in making permission checks., The Javadoc for the check method in StatementPermission
doesn't say anything. The methods have some funky equals methods with no javadoc, without
understanding more it looks like equals is being overloaded for no good reason.
 
StatementPermission has the following hieraracy.. not sure if this will show correctly in
text

StatementPermission
       |
       \----- StatementTablePermission
                                |
                                \------ StatementColumnPermission
       |
       \------ StatementRoutinePermission
       |
       \------ StatementSchemaPermission

All implement check() interface that is used to invoke permission checking for that access
descriptor. Access descriptors already know what they need to check for and are passed current
user authorizationId.

The equals() method is used to check if an access descriptor is already created for the specific
access. For example, a query may have multiple references to same table. No need to create
multiple access descriptors for the same table for the same kind of access. This becomes more
important as each and every column referenced may try to add an access descriptor for the
table in question.

I will add these details to the design part of the spec.

> Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges
than currently provided by Derby that is especially useful in network configurations.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-464
>          URL: http://issues.apache.org/jira/browse/DERBY-464
>      Project: Derby
>         Type: New Feature
>   Components: SQL
>     Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0
>  Environment: generic
>     Reporter: Satheesh Bandaram
>     Assignee: Satheesh Bandaram
>  Attachments: grantRevoke.patch.Dec5, grantRevoke.stat.Dec5, grantRevokeSpec.html
>
> Derby currently provides a very simple permissions scheme, which is quite suitable for
an embedded database system. End users of embedded Derby do not see Derby directly; they talk
to a application that embeds Derby. So Derby left most of the access control work to the application.
Under this scheme, Derby limits access on a per database or per system basis. A user can be
granted full, read-only, or no access. 
> This is less suitable in a general purpose SQL server. When end users or diverse applications
can issue SQL commands directly against the database, Derby must provide more precise mechanisms
to limit who can do what with the database.
> I propose to enhance Derby by implementing a subset of grant/revoke capabilities as specified
by the SQL standard. I envision this work to involve the following tasks, at least:
> 1) Develop a specification of what capabilities I would like to add to Derby.
> 2) Provide a high level implementation scheme.
> 3) Pursue a staged development plan, with support for DDL added to Derby first.
> 4) Add support for runtime checking of these privileges.
> 5) Address migration and upgrade issues from previous releases and from old scheme to
newer database.
> Since I think this is a large task, I would like to invite any interested people to work
with me on this large and important enhancement to Derby.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message