Re: Grant and Revoke, Part I ... DERBY-464...

[Satheesh Bandaram]

Daniel John Debrunner wrote: Satheesh Bandaram wrote 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. 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. 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. 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. 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. 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? 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.