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.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
