[
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 role?
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: 10.3.1.4
> 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.
