[
https://issues.apache.org/jira/browse/CASSANDRA-8650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303224#comment-14303224
]
Sam Tunnicliffe commented on CASSANDRA-8650:
--------------------------------------------
I've given this a bit more thought, particularly in light of CASSANDRA-7557 &
CASSANDRA-7216 and pushed a couple of commits to
https://github.com/beobal/cassandra/tree/8650-v3.
The first commit reworks the {{RolesResource}} concept from the v2 patch here.
In it, roles are represented hierarchically
and so more like {{DataResource}}. The roles hierarchy consists of 2 levels;
the root, which represents the container of all
db roles, and individual roles created by {{CREATE ROLE}} statements. As such,
permissions may be granted on specific roles or on
all roles.
* To {{CREATE}} new roles, the user issuing the statement must have {{CREATE}}
permission on the root level roles resource.
* To {{LIST}} all roles (as opposed to just the roles you have been granted)
requires {{SELECT}} on the root level roles resource.
* To {{DROP}} a role requires {{DROP}} on the specific role, or on the root
level resource.
* To {{ALTER}} a role requires {{ALTER}} on the specific role, or on the root
level resource.
* To {{GRANT}} or {{REVOKE}} a role, the user issuing the statement must
themselves have {{AUTHORIZE}} permission on that role (directly or indirectly).
In addition, to {{CREATE}}, {{DROP}}, {{GRANT}} or {{REVOKE}} a role which has
superuser status (directly or indirectly) the user issuing the statement must
themselves have superuser status.
There is also some filtering done to ensure that {{GRANT (<permission> | ALL)
ON <resource> TO <role>}} only grants meaningful permissions. That is,
{{CREATE}} is not useful to have on a table. Nor does it make sense to have
{{SELECT}} permission on a role.
This approach should be flexible enough to support further {{IResource}}
implementations for other database objects such as functions, aggregates,
triggers etc without requiring lots of similar-but-not-quite-the-same
permissions. i.e. we can safely reuse {{CREATE}}, {{ALTER}}, {{DROP}} etc
without to split them for each resource types - {{CREATE_KEYSPACE}},
{{CREATE_TABLE}}, {{CREATE_FUNCTION}} and so forth. We will still need some new
permissions though, {{EXECUTE}} on functions for example.
The second commit in the branch addresses the issue originally raised in
CASSANDRA-7216. It automatically grants all applicable permissions to the
creator of any new database object (limited initially to keyspaces, tables &
roles). This obviates the need for a superuser (or other role with global
{{AUTHORIZE}} permissions) in a (hypothetical) multitenant configuration .
It might be a good idea to split the two commits between this ticket and 7216.
So if nobody objects I will re-open it, attach the second commit there and make
it dependant on this.
Updated dtests for all of the above at
https://github.com/beobal/cassandra-dtest/tree/cassandra-8650
> Creation and maintenance of roles should not require superuser status
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-8650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8650
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Labels: cql, security
> Fix For: 3.0
>
> Attachments: 8650-v2.txt, 8650.txt
>
>
> Currently, only roles with superuser status are permitted to
> create/drop/grant/revoke roles, which violates the principal of least
> privilege. In addition, in order to run {{ALTER ROLE}} statements a user must
> log in directly as that role or else be a superuser. This requirement
> increases the (ab)use of superuser privileges, especially where roles are
> created without {{LOGIN}} privileges to model groups of permissions granted
> to individual db users. In this scenario, a superuser is always required if
> such roles are to be granted and modified.
> We should add more granular permissions to allow administration of roles
> without requiring superuser status.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
