[
https://issues.apache.org/jira/browse/DERBY-5548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13281007#comment-13281007
]
Rick Hillegas commented on DERBY-5548:
--------------------------------------
Thanks, Dag. If we added a role attribute, then I think we'd eliminate the
syscs_diag.perms_closure vti discussed above. We'd replace it with a different
vti, also having the shape of the SYSPERMS tuple...
syscs_diag.current_perms()
...This vti would return all of the SYSPERMS permissions enjoyed by the current
session. This would include the closure of all SYSPERMS permissions granted to
the current role. We probably wouldn't need to document this vti in the public
api.
The NATIVE authorization service would then operate like this:
1) Connects to $authorizationDB using the user's supplied credentials and role.
This would set the connection to the supplied role.
2) Runs the following query in the resulting connection. Here ? is stuffed with
the permission we're looking for (e.g., CREATE_DATABASE):
select count(*) from table ( syscs_diag.current_perms() ) t
where t.permission = ?;
3) If the query result is non-zero, then the system-wide operation is allowed.
Thanks,
-Rick
> 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
