I wonder if we should look at grant/revoke augmenting the existing
authorization model instead of replacing it.
The existing authorization functionality has:
- disallow a user
- allow a user read-only
- allow a user full-access
Grant/revoke does not replace this functionality, it could be seen as
adding fine-grain control to the read only or read-write access.
Then it seems to come down to how does an application selects the old
model of coarse grain control versus fine grain (grant/revoke).
One way is a property like
derby.database.sqlAuthorization={true|false}
(derby.language.sqlAuthorization ??)
I would like to be able to set a property in derby.properties that made
the default mode for new databases to be grant/revoke.
I think the JDBC attribute (secureMode) is possibly a security risk, if
upgrade to grant/revoke mode is allowed, it seems to allow any remote
user to make that change. Which could allow a denial of service attack
on existing applications. It may be that such an attack could also be
made through setting a database property, but I don't think that's a
justification for adding a new (potential) hole.
Another issue is the potential number of security related properties and
ensuring they are set correctly. If
derby.database.sqlAuthorization=false and a GRANT statement was
executed, then it seems there are three choices:
A - allow the GRANT to succeed, but it is not enforced (since
derby.database.sqlAuthorization=false)
B - throw an exception (warning?) on execution indicating
derby.database.sqlAuthorization=false and thus grant statements are not
applicable
C - Change the database to grant/revoke mode
Maybe B would be the case for a user that was not the database owner
(creator) and C would only be allowed by the database creator.
Also similar exceptions or warnings are probably needed if grant/revoke
is enabled but no authentication is set up.
Dan.
