[
https://issues.apache.org/jira/browse/DERBY-5548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-5548:
-----------------------------------
Labels: derby_triage10_10 (was: )
> Implement a GRANT/REVOKE scheme for authorizing system-wide operations
> ----------------------------------------------------------------------
>
> Key: DERBY-5548
> URL: https://issues.apache.org/jira/browse/DERBY-5548
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Rick Hillegas
> Labels: derby_triage10_10
>
> This is an alternative proposal for how we could authorize system-wide
> operations. Those operations are:
> o Database creation
> o Database restoration
> o Engine shutdown
> o Server shutdown
> o Server startup
> Currently, any valid Derby user can execute all of those operations. This
> leaves Derby-powered applications vulnerable to resource-exhaustion and
> denial-of-service attacks. There is no reason that a data-entry clerk should
> have the power to bring down an enterprise-wide application.
> DERBY-2109 describes our first attempt to implement authorization for
> system-wide operations. The work on that issue was never completed. Under the
> DERBY-2109 scheme, system-wide operations are authorized by entries in the
> application's Java security policy. That scheme has some shortcomings:
> 1) Configuring Java security policy files is tricky. It is easy to make
> mistakes. Furthermore, the policy file reader does not give you much
> assistance in tracking down and correcting those mistakes.
> 2) The scheme only grants privileges to individual users. You can't grant
> system-wide privileges to roles.
> The following alternative scheme builds on the idea of a Credentials DB,
> introduced by the work on DERBY-866. Thanks to Dag for helping puzzle through
> these issues.
> -------------------------------------------------
> A system-wide Credentials DB could be used to store system-wide privileges in
> addition to system-wide credentials. 2 variants of this proposal have been
> considered:
> i) We could introduce some new privileges, extensions to the SQL Standard
> privilege set. The DBO of the Credentials DB could grant and revoke these
> privileges to/from users/roles:
> DERBY_CREATE_DATABASE
> DERBY_RESTORE_DATABASE
> DERBY_SHUTDOWN_ENGINE
> DERBY_SHUTDOWN_SERVER
> DERBY_STARTUP_SERVER
> ii) Alternatively, we could introduce some new system routines to represent
> the system-wide operations. Privilege to perform the operations would depend
> on whether a user/role had been granted EXECUTE privilege on the
> corresponding routines:
> syscs_util.syscs_create_database()
> syscs_util.syscs_restore_database()
> syscs_util.syscs_shutdown_engine()
> syscs_util.syscs_shutdown_server()
> syscs_util.syscs_startup_server()
> A new Derby property would configure whether this authorization scheme should
> be used. This property would be set at the system level, that is, on the JVM
> properties or in derby.properties:
> -Dderby.system.authorization=NATIVE
> If we implemented this scheme in the 10.9 timeframe, then we could default it
> to being on whenever NATIVE authentication was on at the system level. For
> instance, for an application with one database, myDB, NATIVE authentication
> and authorization would both be switched on by setting one knob:
> -Dderby.authentication.provider=NATIVE:myDB
> We could also introduce a new attribute on the connection URL:
> role=roleName
> Here for instance would be the processing flow when a user tried to connect
> with the following URL:
> jdbc:derby:;shutdown=true;user=alice;password=alicepassword;role=sysadmin
> a) A connection would be opened to the Credentials DB using alice's
> credentials.
> b) On that connection, an attempt would be made to "set role sysadmin". If
> that failed, the shutdown would error out.
> c) If the role change succeeded, Derby would verify whether alice or the
> sysadmin role had been granted privilege to shutdown the engine. If not, the
> shutdown would error out.
> d) If the privilege had been granted, then orderly shutdown would be
> performed.
> It should be possible to make this authorization scheme work regardless of
> the authentication scheme being used. That is, it could work regardless of
> whether you were using LDAP, custom, or NATIVE authentication.
> A key advantage of this scheme is that it would be easy to administer using
> familiar GRANT/REVOKE commands.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
