db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini" <francois.ors...@gmail.com>
Subject Re: Grant -revoke (464) and future backwards compat
Date Tue, 21 Feb 2006 19:27:53 GMT
On 2/21/06, Satheesh Bandaram <satheesh@sourcery.org> wrote:
>
>
>  Daniel John Debrunner wrote:
>
>  Satheesh Bandaram wrote:
>
>
>  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.
>
>  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 :-) , 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...
>
>  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?
>

I need to check again and I thought object creation privileges were
granted to some schema owner if that schema had been created explictly
with the CREATE SCHEMA AUTHORIZATION DDL.

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

Agreed - this additional layer has to be flagged in order to be turned
on with its new semantics, no? I thought we had that new property
(derby.database.sqlAuthorization) for that reason (and it can still be
a layer on top of legacy)

>  I see it as compatible, it's an
> additional layer of authorization at the incoming connection level.
>
>  - full-access - Access limited to granted privs.
>
>  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.
>

That is correct. Once sqlStandard is enabled then legacy defined
privileges become more like (specific) Roles for some users to be
granted too - that's the way I see it.

>  Satheesh
>
>

Mime
View raw message