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

[Satheesh Bandaram]

Daniel John Debrunner wrote: I guess I don't understand how 1) is useful. In this mode by adding grant/revoke in its current form you are removing key authorization options. For example if I'm using an LDAP authentication scheme I won't be able to limt the set of authenticated LDAP users who can connect to my database. I can do that now, and with 2) I can do that and have more fine grained authorization. Dan. Right... I was thinking system privileges, when done, will address this issue. I also think second option is best... especially for current Derby customers. I will go update Grant & Revoke functional spec attached to JIRA. I will also discuss some high level design details for Phase II. You suggested adding another property: derby.database.sqlAuthorization={true|false} I think we only want this property being changed from false to true, but not the other way.. correct? If this property is set at system level when a database is created, should Derby automatically make this a database property? This will ensure the property value is moved with the database. What should happen if grant or revoke is issued in a database that has this property set to FALSE or not at all? I thought the consensus was Derby should perform the operation, but raise a warning saying sqlAuthorization is not enabled in that database. Satheesh