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

[Satheesh Bandaram]

I have been thinking if use of properties is the right way to chose sqlStandard security mode or legacy mode... Properties are meant to be more dynamic in nature and since I don't yet plan to allow switching between SqlStandard mode (with support for Grant and Revoke) to legacy mode. I think use of URL property to indicate which security mode is wanted during a database create time is more natural. If one wishes to create a database with support for Grant and Revoke, it could be specified by a URL attribute like secureMode. ij> connect 'jdbc:derby:securedb;create=true;secureMode=true'; If secureMode is not specified, current default of legacy mode database without grant/revoke capability would be created in 10.2 release. If secureMode is true, a database with support for grant/revoke statements is created. In this database, property value of 'defaultConnectionMode' is a no-op. We could also use this mechanism to trigger a legacy database migration to sqlStandard security mode. During booting of a legacy database with secureMode=true could trigger this migration in security mode. Any thoughts or comments? Satheesh Satheesh Bandaram wrote: Let us look at the issues and some assumptions. A solution may follow from it and this definitely needs some debate. The assumptions here are my proposals only. My current proposal (attached to Jira) would allow migrating databases from legacy security mode into sqlStandard mode, but not the otherway. It is preferred to avoid change in behavior to existing applications that may be using defaultConnectionMode. Current default value for defaultConnectionMode is 'fullAccess' and not going to be changed to sqlStandard for 10.2 release. I do think some feedback on how sqlStandard mode is working is needed before any changes. It is possible to have some databases in legacy security mode and some in sqlStandard mode in any installation. sqlStandard mode is likely going to be the default mode at some in the future and likely preferred if not the only mode at long time later. Are these the likely goals for a solution? We could use derby.database.propertiesOnly to override system properties with database properties, but that would change all properties, right? Satheesh Daniel John Debrunner wrote: I'm not sure about this, I can't find what Satheesh is refering to when he said 'Dan raised an important question ...'. I found one comment by me in the thread where I was talking about system properties in general. Databases do have an existing way to override system properties, by setting the database property derby.database.propertiesOnly http://db.apache.org/derby/docs/10.1/tuning/rtunproper24390.html Dan.