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
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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
