db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Grant -revoke (464) and future backwards compat
Date Thu, 16 Feb 2006 23:35:06 GMT
I think we need to answer your question

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

before we consider

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

If I were an app developer, reading something like this would make me 
pretty uncomfortable, as I have no clear safety net to avoid unexpected 
authorization errors in the future.

David

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.
> 
> 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
> 
> derby.database.sqlAuthorization=true
> 
> that behaviour may change in the future, be warned (with possible examples).
> 
> Dan.
> 
> 
> 

Mime
View raw message