[
https://issues.apache.org/jira/browse/CASSANDRA-8650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-8650:
---------------------------------------
Attachment: 8650.txt
A question is on which resource should these new privileges be granted? In this
initial patch I've added a number of new permissions : {{CREATE_ROLE}},
{{DROP_ROLE}}, {{ALTER_ROLE}}, {{GRANT_ROLE}} & {{REVOKE_ROLE}}. As roles are
not intrinsically linked to particular keyspaces or tables, it doesn't make
sense to allow these permissions to be granted at those levels (what would it
mean to have {{CREATE_ROLE}} permissions on a specific keyspace?). So, it is
only valid to grant those permissions at the root resource level, which is
enforced in the CQL syntax. Rather than follow the existing {{GRANT
<permission> ON <resource> TO <grantee>}} syntax, role management privileges
are grouped into a pseudo-role, {{ROLEADMIN}}, which can be granted to regular
roles like so:
{code}
GRANT ROLEADMIN TO foo;
{code}
This statement enables {{foo}} and other roles granted {{foo}} to perform
{{CREATE ROLE}}, {{ALTER ROLE}} & {{DROP ROLE}} statements, plus the ability to
{{GRANT}} and {{REVOKE}} roles. {{foo}} (or any role it is granted to), must
also have {{AUTHORIZE}} permissions on a keyspace or table to be able to grant
permissions to any role created.
Giving or taking away superuser status still requires the actor to be a
superuser. {{GRANT <role> TO <grantee>}} or {{REVOKE <role> FROM <revokee>}}
require superuser status if {{<role>}} has it (either directly or inherited).
Likewise, the {{SUPERUSER}} option may only be used in {{CREATE ROLE <role>}}
and {{ALTER ROLE <role>}} when the logged in user has superuser status.
Finally, {{DROP ROLE <role>}} where {{<role>}} has superuser status also
requires the logged in user to be a superuser.
Modifying other alterable options now requires only the {{ALTER_ROLE}}
permission, not superuser status. For example, a user who has been granted
{{ROLEADMIN}} may modify the password or login status of another role.
dtests added here: 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: Improvement
> Components: Core
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Labels: cql, security
> Fix For: 3.0
>
> Attachments: 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)
