Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <439DF141.3000702@Sourcery.Org>
Date: Mon, 12 Dec 2005 13:53:05 -0800
From: Satheesh Bandaram <satheesh@Sourcery.Org>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: derby-dev@db.apache.org
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.
References: <2047748888.1134361750083.JavaMail.jira@ajax.apache.org>
 <439DDD39.70009@sun.com>
In-Reply-To: <439DDD39.70009@sun.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi David,

I did post the patch for review... I followed up the post after few days
to invite anyone to review again. That time I said I could wait for
review comments or submit then address comments. I also said I would
submit the patch over the next weekend. Since no one replied that either
they want more time or going to review before submission, I submitted
the change.

http://article.gmane.org/gmane.comp.apache.db.derby.devel/11113
http://article.gmane.org/gmane.comp.apache.db.derby.devel/11012

I am willing to address any review comments anyone has. Should I have
waited for more time? I wanted to submit the changes over the weekend to
minimize any disruptions...

Satheesh

David W. Van Couvering wrote:

> 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?
>
> Thanks,
>
> David
>
> 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: 10.0.2.1, 10.1.1.0, 10.2.0.0
>>> 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.
>>
>>
>>