db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.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.
Date Fri, 16 Dec 2005 18:50:23 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
Hi Francois,<br>
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?)<br>
Francois Orsini wrote:<br>
 type="cite">Hi Satheesh,<br>
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...<br>
Btw, these changes cross a few of the Derby subsystems and am hoping
someone can review the query tree and nodes generation (compiler)
  <div><span class="gmail_quote">On 12/11/05, <b
 class="gmail_sendername">Satheesh Bandaram (JIRA)</b> &lt;<a
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
Satheesh Bandaram commented on DERBY-464:
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.<br>
This Phase I implements:<br>
&nbsp;&nbsp;* Grant/Revoke DDL parsing and execution<br>
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.<br>
&nbsp;&nbsp;*&nbsp;&nbsp;Enhancing the syntax for routine creation to include
external-security clause<br>
simple tests to cover only the DDL. I would be expanding on the testing
in the later submissions, including a JUnit test suite.<br>
&nbsp;&nbsp;* Grant/Revoke DDL is only supported if
derby.database.defaultConnectionMode property is set to 'sqlStandard'.<br>
Pending items from Phase I:<br>
&nbsp;&nbsp; 1. dblook needs to be enhanced to emit DDL for grant statements.
&nbsp;&nbsp; 2. Enhanced JUnit based test suite with many more tests.<br>
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.<br>
&nbsp;&nbsp; 4. Updating specification to include schema for new system tables.<br>
&nbsp;&nbsp; 5. Need to change how property defaultConnectionMode is set and/or
&nbsp;&nbsp; 6. Enhance system tables to store external security clause
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.<br>
Also need to support upgrade and migration of legacy databases and
update JDBC metadata.<br>
Let me know if I missed anything else.<br>
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.<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Project: Derby<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Type:
New Feature
&gt;&nbsp;&nbsp; Components: SQL<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; Versions: <a href=""></a>,
 href=""></a>, <a href=""></a><br>
&gt;&nbsp;&nbsp;Environment: generic<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; Reporter: Satheesh Bandaram
&gt;&nbsp;&nbsp;&nbsp;&nbsp; Assignee: Satheesh Bandaram<br>
&gt;&nbsp;&nbsp;Attachments: grant.html, grantRevoke.patch.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
&gt; 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.<br>
&gt; 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:<br>
&gt; 1) Develop a specification of what capabilities I would like to
add to Derby.<br>
&gt; 2) Provide a high level implementation scheme.<br>
&gt; 3) Pursue a staged development plan, with support for DDL added to
Derby first.
&gt; 4) Add support for runtime checking of these privileges.<br>
&gt; 5) Address migration and upgrade issues from previous releases and
from old scheme to newer database.<br>
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.<br>
This message is automatically generated by JIRA.<br>
If you think it was sent incorrectly contact one of the administrators:<br>
&nbsp;&nbsp; <a href="http://issues.apache.org/jira/secure/Administrators.jspa">
For more information on JIRA, see:<br>
&nbsp;&nbsp; <a href="http://www.atlassian.com/software/jira">http://www.atlassian.com/software/jira</a><br>

View raw message