db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2109) System privileges
Date Thu, 14 Dec 2006 00:01:21 GMT
    [ 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

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

> System privileges
> -----------------
>                 Key: DERBY-2109
>                 URL: http://issues.apache.org/jira/browse/DERBY-2109
>             Project: Derby
>          Issue Type: New Feature
>          Components: Security
>    Affects Versions:
>            Reporter: Rick Hillegas
>             Fix For:
>         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


View raw message