db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [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 Mon, 12 Dec 2005 20:27:37 GMT
Hi, Satheesh.  I am still learning the Apache Way, so I wanted to get 
some clarity on how things are generally done.

I know that committers have the merit and trust to commit what they 
want.  I had generally assumed, however, that a large change like this 
should be posted as a patch for review before being committed.

Is the approach that we do an svn diff of the change revision and we can 
send you comments, and you can make changes in response?



Satheesh Bandaram (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12360186 ]

> Satheesh Bandaram commented on DERBY-464:
> -----------------------------------------
> I have submitted Grant and Revoke, Part I to trunk. Let me know if anyone would like
to join developing remaining parts. It is possible to coordinate development using a Wiki.

> This Phase I implements:
>   * Grant/Revoke DDL parsing and execution
>   * Addition of several new system tables to hold the system metadata. I will update
my spec to include detailed schema for new system tables, so that they can be included in
10.2 documentation.
>   *  Enhancing the syntax for routine creation to include external-security clause
>   *  Very simple tests to cover only the DDL. I would be expanding on the testing in
the later submissions, including a JUnit test suite.
>   * Grant/Revoke DDL is only supported if derby.database.defaultConnectionMode property
is set to 'sqlStandard'.
> Pending items from Phase I:
>    1. dblook needs to be enhanced to emit DDL for grant statements.
>    2. Enhanced JUnit based test suite with many more tests. 
>    3. Some implementation improvements possible with the current patch. It should be
possible to combine several new nodes being added, to reduce number of nodes and hence foot
print. Also, the patch adds a Java object to new system tables. While Derby already has some
java objects in its system tables, I think, we should discourage adding new java objects to
catalogs. Since Java objects can't be used in SQL easily, this makes metadata harder to use.
I will explore rewriting SYSCOLPERMS and SYSREQUIREDPERM to not use FormattableBitSet type.
This can be done by having multiple entries in these catalogs for each column referenced.
>    4. Updating specification to include schema for new system tables.
>    5. Need to change how property defaultConnectionMode is set and/or used.
>    6. Enhance system tables to store external security clause specification.
> I am also working on Grant and Revoke, Phase II. This will implement permission checking
for DML statement. Hopefully I will have something to submit by end of January to complete
Phase I and Phase II.
> Also need to support upgrade and migration of legacy databases and update JDBC metadata.
> Let me know if I missed anything else.
>>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:,,
>> Environment: generic
>>    Reporter: Satheesh Bandaram
>>    Assignee: Satheesh Bandaram
>> Attachments: grant.html, grantRevoke.patch.Dec5, grantRevoke.stat.Dec5
>>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.

View raw message