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 Fri, 11 Jan 2008 19:56:34 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558090#action_12558090

Rick Hillegas commented on DERBY-2109:

Hi Dan. The spec describes only one shutdown permission, shutdownEngine. If you have this
privilege, then you can shutdown the engine and you can shutdown the network server too.

As a follow-on patch or effort, we could add a separate shutdownServer permission. If we did
this, then I think that it would make sense that shutdownServer => shutdownEngine. I am
unable to think of a reason that one would want someone to have the ability to shutdown the
VM but not the engine. At first blush, it ought to be possible to implement this relationship
via Permission.implies().

The following cases arise:

1) Neither permission is granted. Neither the server nor the engine can be brought down gracefully.

2) Only shutdownEngine is granted. The engine can be brought down gracefully but the server
cannot be.

3) Only shutdownServer is granted. Both the engine and the server can be brought down gracefully.

4) Both shutdownServer and shutdownEngine are granted. Both the engine and the server can
be brought down gracefully.

(1) and (2) seem like mistakes to me. (3) and (4) look very similar to one another.

Creating a separate shutdownServer permission allows one to have a user who enjoys the permission
to shutdown the engine but not the server. I would like to understand the difference between
the ServerAdministrator and EngineAdmistrator roles. What use-cases are supported by the additional

Here are some approaches which we could take in follow-on patches and efforts:

1) Rename the shutdownEngine permission to just shutdown. That would correspond better with
the behavior described in the spec and implemented in this patch.

2) Either in 10.4 or a later release, implement a separate shutdownEngine permission if the
use-cases seem compelling. The behavior would be shutdown => shutdownEngine.

> System privileges
> -----------------
>                 Key: DERBY-2109
>                 URL: https://issues.apache.org/jira/browse/DERBY-2109
>             Project: Derby
>          Issue Type: New Feature
>          Components: Security
>    Affects Versions:
>            Reporter: Rick Hillegas
>            Assignee: Martin Zaun
>         Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff,
DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat,
DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, SystemPrivilegesBehaviour.html,
systemPrivs.html, systemPrivs.html, 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.
You can reply to this email to add a comment to the issue online.

View raw message