db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Grant -revoke (464) and future backwards compat
Date Tue, 21 Feb 2006 17:45:45 GMT
Satheesh Bandaram wrote:

> Oystein Grovlen - Sun Norway wrote:
>>Daniel John Debrunner wrote:
>>>    - only create schema matching user's name
>>>    - good for now, forwards compatible with the
>>>    future where permission to create any schema
>>>    could be granted explicitly.
>>Does this mean that we will only allow one schema per user?  That
>>seems like a severe limitation.  I guess I am missing something.
> This is where Francois's work on system privileges is needed. Current
> grant/revoke proposal only deals with access privileges to existing
> objects, like ability to grant/revoke select, insert, delete, update or
> allow references/triggers to tables and execute privilege to routines.
> What is sorely needed is ability to grant/revoke system/database access
> and I thought Francois was working on this. Any status Francois?
> Until these system privileges are ready, current proposal limits
> accesses that would cause forward compatibility issues. 

Except that it doesn't, I believe we need additional restrictions on
table and routine creation.

> 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.

> 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.

I'm not sure why "legacy" mode keeps being dragged into this discussion,
or why folks see it as "not compatible". I see it as compatible, it's an
additional layer of authorization at the incoming connection level. It
has three modes in sqlStandard mode:

     - no access - No connection acceess, regardless of any granted privs.

     - read-only access - Connection made read only, read-only access
limited to granted privs. No write access regardless of granted privs.
It is similar to the application calling conn.setReadOnly(true).

     - full-access - Access limited to granted privs.

> I believe Dan is try to
> ensure current proposal doesn't create any future compatibility issues,
> even if in the short term, Derby's new capabilities are restrictive.

Yep, exactly what I'm trying to ensure.


View raw message