On 1/10/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
Well, it is not completely replaced since legacy would still be supported (until sqlStandard is set explicitly)
- Disallow a user to access a database or system can be done via a REVOKE CONNECT statement - it is not part of Satheesh's charter but this is something am looking at as focusing more on System privileges.
- User read-only can be set via a 'read-only' role (known practice).
- User full-access can be set via a 'full-access' role (again this is where ROLE(s) shine)
Sounds good..
Unless it is restricted to the database owner - but I agree this is an issue. I mean without Grant & Revoke *enabled*, there would not be much system privilege check - kinda being able to shutdown a database or the whole system as of today.
At least a warning should be issued to the user as this last one might not have realized that the property had not been set (looking at the other way around) - still the metadata would be updated.
This could be restrictive - We could allow users to set-up grant & revoke privileges and then turning on the sqlStandard authorization mode at a later stage. Of course there could be some issues against existing and running queries but this has to be verified based on the current grant&revoke design.
I don't think that an automatic change of authorization mode would be very welcome by users. Especially if the database is running with users against it.
Warnings would be good...
I wonder if we should look at grant/revoke augmenting the existing
authorization model instead of replacing it.
Well, it is not completely replaced since legacy would still be supported (until sqlStandard is set explicitly)
The existing authorization functionality has:
- disallow a user
- allow a user read-only
- allow a user full-access
- Disallow a user to access a database or system can be done via a REVOKE CONNECT statement - it is not part of Satheesh's charter but this is something am looking at as focusing more on System privileges.
- User read-only can be set via a 'read-only' role (known practice).
- User full-access can be set via a 'full-access' role (again this is where ROLE(s) shine)
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.
Sounds good..
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.
Unless it is restricted to the database owner - but I agree this is an issue. I mean without Grant & Revoke *enabled*, there would not be much system privilege check - kinda being able to shutdown a database or the whole system as of today.
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 )
At least a warning should be issued to the user as this last one might not have realized that the property had not been set (looking at the other way around) - still the metadata would be updated.
B - throw an exception (warning?) on execution indicating
derby.database.sqlAuthorization=false and thus grant statements are not
applicable
This could be restrictive - We could allow users to set-up grant & revoke privileges and then turning on the sqlStandard authorization mode at a later stage. Of course there could be some issues against existing and running queries but this has to be verified based on the current grant&revoke design.
C - Change the database to grant/revoke mode
I don't think that an automatic change of authorization mode would be very welcome by users. Especially if the database is running with users against it.
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.
Warnings would be good...
Dan.
