db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Grant -revoke (464) and future backwards compat
Date Thu, 16 Feb 2006 21:20:53 GMT
The reason that grant/revoke (DERBY-464) has to add a mode


is that the grant/revoke requires a different access model to Derby's
current model.

The current model is any full access user has access to any schema object.

The SQL model is that only the creator of the table has access to the
table, but can grant fine grained access to others.

Changing Derby to the default or the SQL model or only supporting the
SQL model would break existing applications. Hence the dual mode.

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}


So I'm wondering if there is anything more that needs to be done (in
addition to 464 - which is a good incremental step) to prevent mode hell
in the future. (There's a certain other open source database that now
has many mode settings, imagine trying to support that, "ok now try
turning that mode off and this one on", "or which mode settings do you
have on, do you really know?").

A possible free reign for users after 464 is the ability to create a
schema corresponding to the user's name and thus create any SQL objects
you want in the database. So I can create a table and populate it with
100 million rows to bring the database down by filling the disk up.

It almost seems like some create schema permission would avoid us having
a mode in the future that was:

 - 10.2 anyone can create a schema and objects within it
 - future - support full grant/revoke mode with schema creation permission.

Now I looked briefly in the SQL2003 standard and the does not seem to be
any create schema permission, and the access permission under create
table was the less than obvious:

"If a <table definition> is contained in an <SQL-client module
definition>, then the enabled authorization
identifiers shall include A."

"A" being an authorization identifier, I need to follow that chain more.

Maybe the more general question is: "How do we want permissions to
behave once all the related work is done, and does that model have any
discontinuities with the model currently proposed for 10.2?"

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


that behaviour may change in the future, be warned (with possible examples).


View raw message