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 "Satheesh Bandaram (JIRA)" <de...@db.apache.org> on 2005/12/12 05:29:10 UTC
[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.
[ 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.
--
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
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.
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Thanks, Sateesh. Sorry, I missed the request for review comments. No
need; I personally am not able at this time to review your changes. I
just thought this was the first time we saw these changes. My mistake.
David
Satheesh Bandaram wrote:
> 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.
>>>
>>>
>>>
>
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.
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
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.
>>
>>
>>
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.
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
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.
>
>
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.
Posted by Francois Orsini <fr...@gmail.com>.
Thanks Satheesh - much appreciated ;)
On 12/16/05, Satheesh Bandaram <sa...@sourcery.org> wrote:
>
> Hi Francois,
>
> I will update functional specification with system table schema. I will
> also add a high level design section there with some details. I am little
> pressed for time right now, but will get this out next week. (happens to be
> my off week, but open source world never sleeps, right?)
>
> Satheesh
>
> Francois Orsini wrote:
>
> Hi Satheesh,
>
> I'm reviewing the part I changes you checked-in - there is a lot of
> changes and it is somewhat tedious to understand some of the decisions that
> have been made at the implementation level - not saying anything is wrong -
> it is just hard to follow certain paths without a minimum of high-level
> technical details about the implementation (i.e. design specs) and mostly
> because of the amount of changes - there are classes without headers, which
> makes it difficult to understand the purpose of a class - sure, one can
> always spend a long time trying to understand things but I think for patches
> with such amount of changes, some high-level design details would be
> appreciated by the reviewers...I know you intended to post details about the
> system catalogs but right now one has to review the changes without a lot of
> details besides the functional specs...a 1-2 pager high-level implementation
> details would not just help reviewers to do a better appreciation of the
> changes but also incentivize more reviewers to look at the changes...
>
> Btw, these changes cross a few of the Derby subsystems and am hoping
> someone can review the query tree and nodes generation (compiler) stuffs...
>
> Thanks,
>
> --francois
>
> On 12/11/05, Satheesh Bandaram (JIRA) <de...@db.apache.org> 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.
> >
> > --
> > 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
> >
> >
>
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.
Posted by Francois Orsini <fr...@gmail.com>.
Hi Satheesh,
I'm reviewing the part I changes you checked-in - there is a lot of changes
and it is somewhat tedious to understand some of the decisions that have
been made at the implementation level - not saying anything is wrong - it is
just hard to follow certain paths without a minimum of high-level technical
details about the implementation (i.e. design specs) and mostly because of
the amount of changes - there are classes without headers, which makes it
difficult to understand the purpose of a class - sure, one can always spend
a long time trying to understand things but I think for patches with such
amount of changes, some high-level design details would be appreciated by
the reviewers...I know you intended to post details about the system
catalogs but right now one has to review the changes without a lot of
details besides the functional specs...a 1-2 pager high-level implementation
details would not just help reviewers to do a better appreciation of the
changes but also incentivize more reviewers to look at the changes...
Btw, these changes cross a few of the Derby subsystems and am hoping someone
can review the query tree and nodes generation (compiler) stuffs...
Thanks,
--francois
On 12/11/05, Satheesh Bandaram (JIRA) <de...@db.apache.org> 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.
>
> --
> 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
>
>