[ http://issues.apache.org/jira/browse/DERBY-2109?page=comments#action_12458530 ] Øystein Grøvlen commented on DERBY-2109: ----------------------------------------
Rick Hillegas (JIRA) wrote: > [ > 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. > Good, and I agree with Dan that a command for explicit reloading is probably best. > 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. > I guess most people should be able to manage the editing of files etc. I foresee that some users will be a bit confused about the location of such files, but that is a more general issue. > 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. I see your point, but I do not think many organizations will find it practical to deny database owners to be able to create plugins. Hence, you might as well make it a database-specific feature. > > 4) Appendix A issue. I believe that Dag answered this one. Thanks, Dag! Yes, and his answer made me realize that restore is missing from this spec. > > 5) My imagination deficit. As I said to David, I will reword these sentences. > Great. > 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. I agree. We need provide roles in order make this really usable. > 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. In other words, for createDatabase you provide the list of potential database owners. But then in order to allow one person to create one database in one specific place, you allow him to create as many databases he wants wherever he likes. An alternative could be to only allow System Administrators to create databases, and provide a way to specify database owner when you create the database. > 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
