On 1/16/06, Satheesh Bandaram <[EMAIL PROTECTED]> wrote:
Yes and I will be posting more details very soon.
Combining both modes sounds interesting as long as it does not impact runtime performance by much (since permission checks would have to be done in the 2 realms) and it seems to me that runtime permission checking would get more complicated which we should try to avoid as it is in the main compilation/execution path - permission resolution check would be more complicated IMO - I understand the motivation for bringing them to Grant/Revoke mode but it can also be confusing for users to mix both modes (i.e. different semantics and syntax being mixed) - If Grant/Revoke is always enabled but there is no metadata (including legacy one), then I believe a user would not have access by default to anything except his/her own schema (objects). By default, when no legacy permissions are set, the default access for a database is full (read-write) access, which would be different for Grant/Revoke whereas explicit privileges have to be granted for a user to access a table that is not his/her - Again we're dealing with different semantics across modes which IMHO should not be mixed.
This case/scenario would indeed be very good for users to prepare and switch to sqlAuthorization when all the metadata is there - meaning they would have issued all the required Grant/Revoke statements to satisfy what they had with the legacy mode (*assuming* there is support for Roles and System privileges which is something I'm working on) - it is a nice way for people to migrate from legacy to grant/revoke IMO.
Daniel John Debrunner wrote:
You do raise good points, as usual. I see your argument for ease of migration as the most compelling reason to avoid two different security models. Since Francois said he is working on adding system privileges and/or roles, hopefully your other concerns would be met at some point.Satheesh Bandaram wroteI 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.
I'm more proposing this to deal with existing Derby applications and
finding an easy way to bring them into the new world of grant revoke.
Yes and I will be posting more details very soon.
If we are proposing combining both authorization models, why not go the whole way and say Grant/Revoke is always enabled in a 10.2 database? If applications want to keep their current authorization model, they don't need to use new fine-grained access control allowed by grant/revoke. This preserves legacy model for them.
Combining both modes sounds interesting as long as it does not impact runtime performance by much (since permission checks would have to be done in the 2 realms) and it seems to me that runtime permission checking would get more complicated which we should try to avoid as it is in the main compilation/execution path - permission resolution check would be more complicated IMO - I understand the motivation for bringing them to Grant/Revoke mode but it can also be confusing for users to mix both modes (i.e. different semantics and syntax being mixed) - If Grant/Revoke is always enabled but there is no metadata (including legacy one), then I believe a user would not have access by default to anything except his/her own schema (objects). By default, when no legacy permissions are set, the default access for a database is full (read-write) access, which would be different for Grant/Revoke whereas explicit privileges have to be granted for a user to access a table that is not his/her - Again we're dealing with different semantics across modes which IMHO should not be mixed.
10.2 databases could use grant/revoke to get more control over access to their objects. Hopefully Derby will also have system privileges and roles to complete this model at some point. This proposal removes the need to have another property, like 'derby.database.sqlAuthorization'. One advantage I see with this is that we don't need to handle the case of someone issuing Grant/Revoke with sqlAuthorization set to false and trying to find appropriate time to switch the authorization scheme.
This case/scenario would indeed be very good for users to prepare and switch to sqlAuthorization when all the metadata is there - meaning they would have issued all the required Grant/Revoke statements to satisfy what they had with the legacy mode (*assuming* there is support for Roles and System privileges which is something I'm working on) - it is a nice way for people to migrate from legacy to grant/revoke IMO.
Once issue I see is how to handle EXTERNAL SECURITY clause in this combined authorization model. Current legacy databases have EXTERNAL SECURITY set to INVOKER, where as my proposal calls for changing this to DEFINER. This could be seen as changing the behavior of Derby without sufficient warning. We could address this by one of the following:
- Automatically moving existing routines to INVOKER security mode during database upgrade to 10.2 and making all new routine creation mandating specifying this security clause. (No default) Would help users to consider one or the other model. We could add a default for this clause to DEFINER (as specified by ANSI) later.
- Move existing routines to INVOKER during upgrade and by switching default behavior to DEFINER with sufficient warning messages to release notes and by raising SQL warning if a default mode of DEFINER is picked.
- Any other suggestions?
My
suggestion would be not to mix 2 different authorization modes unless
we absolutely have to, if it does not impact performance and does not
add too much complexity to the runtime permission checking logic.
As a first phase for Roles and System privileges support (which are independent), am working on implementing what is required at a minimum to support what's there in legacy to be available with Grant/Revoke as well as adding critical and minimal System privileges that have to be supported in Derby.
As a first phase for Roles and System privileges support (which are independent), am working on implementing what is required at a minimum to support what's there in legacy to be available with Grant/Revoke as well as adding critical and minimal System privileges that have to be supported in Derby.
It would be good to drive to a decision soon. I am making progress on second part of Grant/Revoke, implementing the permission scheme enforcement.
Satheesh
Users familiar with the ansi subset model would just use that, no need
to get involved with the defaultConnectionModel. Though until roles and
system privileges is supported, they might need to to ensure a secure
system. I haven't seen any proposal on these roles or system privileges
so I'm looking at how secure Derby will be in its next release given
what has been proposed and is being worked on. If we have a release
about 6 months from the last one, it will be around March. I think
someone was going to set up a wiki page with what "10.3" would include,
though that hasn't happened yet.
Dan.
