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 19:37:59 GMT
Satheesh Bandaram 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 looked at some other databases (Oracle, DB2, Postgres) and the typical
model is to require a database level privilege to create tables or call
an external routine.

Create table I could possibly go either way on, but if we followed the
de-facto standard model of other databases then we need a database level
privilege.

Creating an external routine would have all sorts of security concerns
for a database owner, it's allowing a remote user to execute code on
their system.

Dan.

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

I think we are in agreement, but talking about different things.

Introducing grant/revoke causes behaviour incompatible (when enabled)
with previous releases.

The connection based authorization model (noAccess, readOnly or full) by
itself is not incompatible with grant/revoke.

Dan.


Mime
View raw message