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 -revoke (464) and future backwards compat
Date Tue, 21 Feb 2006 19:02:48 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">
<br>
<br>
Daniel John Debrunner wrote:<br>
<blockquote cite="mid43FB51C9.1000808@apache.org" type="cite">
  <pre wrap="">Satheesh Bandaram wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">
Until these system privileges are ready, current proposal limits
accesses that would cause forward compatibility issues. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Except that it doesn't, I believe we need additional restrictions on
table and routine creation.
  </pre>
</blockquote>
In sqlStandard mode, the proposal only allows for creating tables and
routines in their own Schema and no where else. I thought this is too
restrictive already<span class="moz-smiley-s1"><span> :-) </span></span>,
but makes sense that unless someone grants ability to create tables in
their schema, Derby shouldn't allow that. Currently there is no way to
grant privilege to create tables...<br>
<br>
What future scenario do you see where schema owners don't have ability
to create tables or routines in their own schema, by default? It may be
possible that Derby would allow granting/revoking table or routine
privileges in the future, but default behavior for a schema owner would
be to have this privilege by default?<br>
<blockquote cite="mid43FB51C9.1000808@apache.org" type="cite">
  <blockquote type="cite">
    <pre wrap="">If sqlStandard
mode allows unrestricted schema creation now, this would cause issues in
the future where existing applications may need to change or we have to
introduce another property like what is being done now.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">Current legacy
authorization model is not compatible with standard model or what Derby
might really want to support, but at the same time, we can't drop
support for it because of existing applications.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I'm not sure why "legacy" mode keeps being dragged into this discussion,
or why folks see it as "not compatible".</pre>
</blockquote>
If current or legacy mode is compatible with sqlStandard mode, would
there be a need to add new property, derby.database.sqlAuthorization? I
understand going forward defaultConnectionMode can be seen as
compatible with standard model as additional layer of authorization,
but I see there is a break from 10.1 model to 10.2.<br>
<blockquote cite="mid43FB51C9.1000808@apache.org" type="cite">
  <pre wrap=""> I see it as compatible, it's an
additional layer of authorization at the incoming connection level.

     - full-access - Access limited to granted privs.
  </pre>
</blockquote>
The way I see it, Derby is essentially changing full-access meaning...
from "read/write access to every object in the database" to "read/write
access to objects owned or been granted limited access to" in
sqlStandard mode. This would force existing applications to change to
adapt to sqlStandard mode, right? If so, we have an incompatibility.<br>
<br>
Satheesh<br>
<br>
</body>
</html>


Mime
View raw message