[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463724
]
Rick Hillegas commented on DERBY-2109:
--------------------------------------
Daniel John Debrunner (JIRA) wrote:
>Just to add to this, it would be wise to define the format for the database
>location carefully to ensure the model works for future enhancments, such as
>the ability to limit shutdown of a database in a jar file, >or creation of
>some non-file based database.
>
I>n the spec it says:
">The directoryLocation argument has the format of a directory reference in a
declaration of a FilePermission permission. "
>
>Databases can be more than files though, should the target for this permission
>be in the format of a database name from a JDBC URL or DataSource databaseName
>property?
Maybe we could require that the database location be unambiguously qualified by
one of the subsubprotocols which we recognize on URLs:
classpath:
directory:
jar:
So, for instance, in this first rev:
permission org.apache.derby.security.DatabasePermission
"directory:${derby.system.home}${/}accountingDBA" "create";
and in some later rev when we support other kinds of DatabasePermissions:
permission org.apache.derby.security.DatabasePermission "jar:/maps/USmaps"
"shutdown";
and if we added a new subsubprotocol for in-memory databases:
permission org.apache.derby.security.DatabasePermission
"memory:/users/fred/-" "create";
> System privileges
> -----------------
>
> Key: DERBY-2109
> URL: https://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, 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:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
