[ http://issues.apache.org/jira/browse/DERBY-2109?page=comments#action_12458313 ] Rick Hillegas commented on DERBY-2109: --------------------------------------
Thanks for your comments, Øystein. A couple responses follow: 1) Dynamically changing the policy file. The policy file can be dynamically reloaded after you edit it and without restarting the VM. Some code has to call java.security.Policy.getPolicy().refresh(). This requires granting that code the following permission: java.security.SecurityPermission "getPolicy" Thanks for broaching this topic. We could always reload the policy file just before checking for a system privilege and then advise the user to grant derby.jar the above permission. 2) Unfamiliar api. Oracle, DB2, Postgres, and MySQL all handle system privileges in different ways. Picking one of these models would still result in an api that's unfamiliar to many people. That said, these databases do tend to use GRANT/REVOKE for system privileges, albeit each in its own peculiar fashion. I agree that GRANT/REVOKE is an easier model to learn than Java Security. I think however, that the complexity of Java Security is borne by the derby-dev developer, not by the customer. Creating a policy file is very easy and our user documentation gives simple examples which the naive user can just crib. With adequate user documentation, I think this approach would be straightforward for the customer. 3) Plugin scope. I think that you and Dan agree that "plugin" is a database-specific, not a system-wide privilege. My first reaction (still recorded in the description block for this JIRA) also listed "plugin" as a database-wide privilege. I can argue the issue both ways. On the one hand, the "plugin" power potentially gives the user the ability to expose/exploit code which has system-wide effects. On the other hand, the affected objects (jars, functions, procedures) are all scoped to the database level. I am happy to treat "plugin" as a database-specific privilege. 4) Appendix A issue. I believe that Dag answered this one. Thanks, Dag! 5) My imagination deficit. As I said to David, I will reword these sentences. 6) User management and role migration. I suspect that the introduction of SQL roles will help address your concerns about database-specific privileges: we should be able to introduce a DB_OWNER role. In addition, as the spec notes, a follow-on usability feature could introduce the power to change the owner of a database. I think we're in better shape for system-wide privileges managed by Java security. Here the system administrator can edit the policy file as necessary. 7) Granularity of system-wide privileges. I see no problem in starting out lumping all the database-specific privileges together and letting the database owner hoard them. They are all privileges which a database owner would want. The two system-wide privileges belong to different roles: shutdownEngine belongs to the system administrator and createDatabase belongs to the various database owners. That is the motivation for the granularity of system-wide privileges. > System privileges > ----------------- > > Key: DERBY-2109 > URL: http://issues.apache.org/jira/browse/DERBY-2109 > Project: Derby > Issue Type: New Feature > Components: Security > Affects Versions: 10.3.0.0 > Reporter: Rick Hillegas > Fix For: 10.3.0.0 > > Attachments: systemPrivs.html > > > Add mechanisms for controlling system-level privileges in Derby. See the > related email discussion at > http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. > The 10.2 GRANT/REVOKE work was a big step forward in making Derby more > secure in a client/server configuration. I'd like to plug more client/server > security holes in 10.3. In particular, I'd like to focus on authorization > issues which the ANSI spec doesn't address. > Here are the important issues which came out of the email discussion. > Missing privileges that are above the level of a single database: > - Create Database > - Shutdown all databases > - Shutdown System > Missing privileges specific to a particular database: > - Shutdown that Database > - Encrypt that database > - Upgrade database > - Create (in that Database) Java Plugins (currently Functions/Procedures, > but someday Aggregates and VTIs) > Note that 10.2 gave us GRANT/REVOKE control over the following > database-specific issues, via granting execute privilege to system > procedures: > Jar Handling > Backup Routines > Admin Routines > Import/Export > Property Handling > Check Table > In addition, since 10.0, the privilege of connecting to a database has been > controlled by two properties (derby.database.fullAccessUsers and > derby.database.defaultConnectionMode) as described in the security section of > the Developer's Guide (see > http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
