Daniel John Debrunner wrote:
>I wonder if we should look at grant/revoke augmenting the existing
>authorization model instead of replacing it.
>
>
>
Why would we want to augment the new authorization model with the old
one? Is there something that old model provides that new model doesn't
have? I think mixing both will lead to confusion to users many already
familiar with the ansi subset model being proposed. This will also
create hurdles as we expand authorization scheme to support roles and
"system privileges" as Francois calls them and other security capabilities.
>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.
>
>
The new model does allow this access, with fine-grain control. How would
we handle the case of a read-only user having INSERT privilege? Guess we
could make read-only access override INSERT privilege.
>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.
>
>
I think we already have a security hole like this... Remote users can
upgrade a database for you when the Sysadm intent may have been to use
the database in soft upgrade mode. This kind of security holes are best
plugged by adding support for roles or system privileges to have Sysadm
privilege. Francois may be working on something in this area...
>Another issue is the potential number of security related properties and
>ensuring they are set correctly. If
>
>
You are proposing to add another one! The list below can be pretty
confusing if not deceiving to new or beginner users to Derby.
Satheesh
>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.
>
>
>
>
>
