[
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
database?
* 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
usable.
* 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: 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
