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.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
