Satheesh Bandaram wrote:
> Oystein Grovlen - Sun Norway wrote:
>
>
>>Daniel John Debrunner wrote:
>>
>>
>>>CREATE SCHEMA
>>> - 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.
Thanks,
Dan.