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 Sun, 25 Dec 2005 12:15:34 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Some answers below....<br>
<br>
Daniel John Debrunner (JIRA) wrote:
<blockquote
 cite="mid50952164.1135448191624.JavaMail.jira@ajax.apache.org"
 type="cite">
  <pre wrap="">    [ <a class="moz-txt-link-freetext" href="http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12361221">http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12361221</a>
] 

spec&gt; DDL statements directly invoke executing mechanism simplify the implementation
at the cost of a small increase in execution time.

I don't think that's true. DDL''s are not slower due to using a constant action. That's not
the reason for the way they are handled. I think the basic idea is that DDL's are limited
in structure compared to DML and can easily be represented by an object that represents an
action and a set of constants. DDL did  generate a java class to execute the constant action
but I cleaned that up to use a fixed implementation (sub-class) of BaseActivation , as otherwise
each DDL would be generating an identical class. This was wasteful when most DDL is discarded
after a single execution.
  </pre>
</blockquote>
One side-effect of directly executing DDLs is that they need to be
compiled everytime... I think that is what I was refering to.. though I
don't see many useful cases where sharing a DDL plan would be useful. I
will modify the line.<br>
<blockquote
 cite="mid50952164.1135448191624.JavaMail.jira@ajax.apache.org"
 type="cite">
  <pre wrap="">In various tables you have the user name represented (I think) as VARCHAR(30)
(GRANTEE, GRANTOR columns). Why 30? In the existing SYSSCHEMAs the user identifer is VARCHAR(128),
I think 128 is a better limit for user names.
  </pre>
</blockquote>
Derby currently recognises user names of upto 30 only, not longer... It
raises errors, though not very clear from the error message itself. Try
having a longer name than 30 characters in the URL. Still, may be I
could change the size in the catalog to 128, which would allow any
changes to this size in the future.<br>
<blockquote
 cite="mid50952164.1135448191624.JavaMail.jira@ajax.apache.org"
 type="cite">
  <pre wrap="">spec&gt; Permission checking is done at execution time.

Could you expand on that? Are you going to match the current scheme, permissions checked when
an internal ResultSet is created? Something else? 
  </pre>
</blockquote>
I will expand on the run-time issues little later... I am still
developing this area.<br>
<blockquote
 cite="mid50952164.1135448191624.JavaMail.jira@ajax.apache.org"
 type="cite">
  <pre wrap="">spec&gt; The permission checks could be done at compilation time.

For the reasons given I think this is a bad idea, the statement cache. I do think we can set
it up so that permissions are checked when the statement is prepared by the application, even
when it picks up an existing compiled plan. This would be better than per execution of the
statement. That's probably a separate discussion once you reveal what you are currently planning.

spec &gt; The permission checks could be done at compilation time. PreparedStatements
would have to be re-compiled when permissions are revoked, as they are recompiled when tables
are altered.

Don't you have to recompile statement plans when permissions are revoked or granted? Even
if you are checking permissions at execution time?

Can you document the locking plans (e.g. what locks does grant get) and the interaction with
the dependency system. I think these are key to getting the design right and secure. 

  </pre>
</blockquote>
I will cover these in more details... once I make more progress... <br>
<br>
Satheesh<br>
<blockquote
 cite="mid50952164.1135448191624.JavaMail.jira@ajax.apache.org"
 type="cite">
  <pre wrap="">

  </pre>
  <blockquote type="cite">
    <pre wrap="">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: <a class="moz-txt-link-freetext" href="http://issues.apache.org/jira/browse/DERBY-464">http://issues.apache.org/jira/browse/DERBY-464</a>
     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, grantRevokeDec23.html

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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>


Mime
View raw message