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: Grant and Revoke, Part II ... DERBY-464...
Date Thu, 16 Feb 2006 08:33:21 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Francois,<br>
<br>
I just updated Grant and Revoke specification in JIRA. Take a look at
the spec and let me know if you still have any questions. Many of your
comments here are already handled there.<br>
<br>
Satheesh<br>
<br>
Francois Orsini wrote:<br>
<blockquote
 cite="mid7921d3e40602151551j73bbd4e0rff50bdaf8fb3dc25@mail.gmail.com"
 type="cite">
  <pre wrap="">Hi Satheesh,

Please find my comments enclosed below:

On 2/8/06, Satheesh Bandaram <a class="moz-txt-link-rfc2396E" href="mailto:satheesh@sourcery.org">&lt;satheesh@sourcery.org&gt;</a>
wrote:
[...]
  </pre>
  <blockquote type="cite">
    <pre wrap=""> I am not sure if previous discussion about migrating a legacy mode
database
to Grant Revoke model was finalized. It seems there were two thoughts:


1. Keep authorization models separate. Legacy mode database can be migrated to
sqlStandard model by connecting with a URL property. (sqlAuthorization=true)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
How to restrict anyone to specify this new URL property? This is a
system privilege by itself that would need to be granted unless it is
a user with an 'ADMIN' role (which we don't have yet). Are we also
going to allow users to move from legacy to grant/revoke during the
database upgrade phase? I thought so.

  </pre>
  <blockquote type="cite">
    <pre wrap="">2. Dan proposed combining both models with Grant and Revoke capability
being
seen as adding fine-grain access control on top of current model. While this
proposal doesn't impact Grant and Revoke work being done currently by much,
it may have implications on some future work. (like system privileges) This
does make it easier for existing databases to adapt new capabilities.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I remember we discussed this - This sounds good if Ansi ROLES are not
there but when they are, then equivalent roles for the various legacy
authorization modes can be defined to act the same way. For instance,
a role for a 'read-only' authorization identifier (i.e. user/role) can
be defined to act the same as legacy
'derby.database.readOnlyAccessUsers', etc - you just assign some
defined 'READ_ONLY' role to the users that you reference as part of
the derby.database.readOnlyAccessUsers' derby property...Hence, no
need to mix 2 authorization modes of different standards but until
ROLES are there I agree with Dan this is a *must* to have...

  </pre>
  <blockquote type="cite">
    <pre wrap=""> Satheesh

 Daniel John Debrunner wrote:

 Satheesh Bandaram wrote:


 I think mixing both will lead to confusion to users many already
familiar with the ansi subset model being proposed. This will also
create hurdles as we expand authorization scheme to support roles and
"system privileges" as Francois calls them and other security capabilities.

 I'm more proposing this to deal with existing Derby applications and
finding an easy way to bring them into the new world of grant revoke.
Users familiar with the ansi subset model would just use that, no need
to get involved with the defaultConnectionModel. Though until roles and
system privileges is supported, they might need to to ensure a secure
system. I haven't seen any proposal on these roles or system privileges
so I'm looking at how secure Derby will be in its next release given
what has been proposed and is being worked on.

Dan.

    </pre>
  </blockquote>
  <pre wrap=""><!---->


  </pre>
</blockquote>
</body>
</html>


Mime
View raw message