[ 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)