db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <j...@apache.org>
Subject [jira] Commented: (DERBY-2109) System privileges
Date Thu, 14 Dec 2006 15:59:29 GMT
    [ 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

> 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.

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:
>            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