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 Sat, 18 Feb 2006 00:04:15 GMT
The legacy 'defaultConnectionMode' access mode was implemented as a
simplistic authorization model, mostly aimed at embedded applications
back then. It was also meant to ease application development as by
default a user is in full-access mode.

Legacy access mode needs to be kept because if not, application out
there using it would fail - even if we had a substitute (ANSI Grant &
Revoke) and some logic to emulate what legacy did (by adding
predifined ROLES corresponding to the various legacy access modes), we
would still need to keep around as end-users may have script using the
legacy syntax - I know this is not a discussion about removing legacy
access mode or not but as it is going to be there (until it gets
deprecated and if it ever happens) for now, we need to have an access
mode switch property - we can make both access modes work at runtime,
but we still need a property to tell derby that sqlStandard mode is
now in effect and it's no longer  a default of fullAccess mode.

We need to document "activation" of the ANSI Grant & Revoke mode very
carefully with the impact on existing application if it were to be
turned ON by some user.  This leads to another issue with the lack of
System Privileges at the moment to ensure that you're not going to
have (any) user (re)setting a database property in your back...At
least the sqlAuthorization property cannot be reset as Satheesh
mentioned already in the specs.

What we could do is raise a big Warning message the first time this
property ('sqlAuthorization ') is set to true and have the user
execute it a second time to confirm the action. I've seen this done
elsewhere as a confirmation mechanism to important configuration
properties.

As far as CREATE SCHEMA,  a user would need to be granted a specific
system privilege to allow a user to create some schema...same way as
CREATE TABLE, etc....or have some kind of DBA role (when ANSI SQL
ROLES are available)...

--francois

On 2/16/06, Satheesh Bandaram <satheesh@sourcery.org> wrote:
>
>  Daniel John Debrunner wrote:
>
>  The reason that grant/revoke (DERBY-464) has to add a mode
>
> derby.database.sqlAuthorization={true|false}
>
> is that the grant/revoke requires a different access model to Derby's
> current model.
>
>  I am still not satisfied this is the right way to switch authorization
> models. Could having a system procedure to switch mode from legacy
> authorization to standard authorization be better? This property can only be
> changed from false to true and need special code to ensure this.
>
>  I'd like to ensure that we don't need to introduce another mode switch
> in a future release, related to this area. Ending up several releases
> from now with these properties would be bad
>
> 10.3
> derby.database.sqlAuthorizationWeReallyMeanItThisTime={true|false}
>
> 10.4
> derby.database.sqlAuthorizationOKMaybeThisTime={true|false}
>
> :-)
>
>  This is a problem... I think it would be wise to advise users to follow SQL
> standard mode of operation or any other that we may enhance derby to in the
> future.
>
>
>  Maybe there's other work that needs to be done to avoid jarring mode
> switches in the future.
>
> The alternative is to document, for 10.2, when
>
> derby.database.sqlAuthorization=true
>
> that behaviour may change in the future, be warned (with possible examples).
>
>  It should be ok to document recommended practices... no?
>
>  Satheesh
>
>

Mime
View raw message