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 Wed, 13 Dec 2006 13:27:23 GMT
    [ http://issues.apache.org/jira/browse/DERBY-2109?page=comments#action_12458110 ] 
Øystein Grøvlen commented on DERBY-2109:

Thanks for taking on this work Rick.  I think it is very important
improve such security issues in order to have a good story with
respect to deployment of a Derby network server.  Here are my
comments/questions to the document:

   * I think my biggest concern with the proposed scheme for
     system-wide privileges is that it seems to fall into the same
     category as Derby's static properties.  That is, you will have to
     restart the server in order for changes to take effect.  While
     this is OK as a starting point, how difficult will it be to
     extend this to allow privileges to be granted and revoked without
     having to restart the server?  Does the Java security framework
     have any support for run-time changes?

   * While it may be true that the Java Security framework might be
     familiar to users who currently use the Security Manager, I am
     not sure that is the case for the average users that would like
     to use system privileges.  I think a lot more people will be more
     concerned about applications shutting down the server by
     accident, than that applications may write stuff where they
     should not.  Your proposal is not particulary familiar to DBA's
     that have experience from other RDBMS like MySQL, Postgres,
     Oracle, or DB2.  However, you can argue that the familiarity
     issue is much larger with the way Derby does user management so
     that this does not add much to the existing problem. :-)

   * I do not understand why plugins are a system-wide features.  Are
     we not talking about objects that are local to a specific

   * I miss a rationale for how you ended up with three
     database-specific features.  What are particular to them compared
     to other features like those listed in Appendix A? 

   * As others, I react to statements like "We don't see why anyone
     other than the database owner would need to ...".  I can see many
     reasons to the contrary.  I guess want you mean is "We think it
     is an acceptable restriction that only the database owner is
     allowed to ...".  I think the whole problem here is that database
     owner is really a role and not a particular person, and that we
     need to be able to define roles in order to make this really

   * You say that the above can be solved by creating special accounts
     for the system/database administrator roles.  At the same time we
     advertising the usefulness of pluggable user authentication.  I
     do not feel these stories fit well together.  You may have
     limited freedom to create specific users if you depend on
     external user authentication.

   * While all database-specific privileges is lumped into one
     user/role, the system administrator privileges can be specified
     one by one.  Is there any particular reason for the finer
     granularity for system 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:
>            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