[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745178#comment-17745178
]
Maxim Chanturiay commented on CASSANDRA-18018:
----------------------------------------------
[~samt] [~skoppu] , hello!
It's been a minute, but I've finally cooked something here:
[https://github.com/apache/cassandra/pull/2504].
It is based on [~samt]'s past comments. There is nothing new in terms of output
- but a simple refinement of LIST ROLES query with options.
[~skoppu] there is an option to filter roles that have or do not have superuser
status.
I think it will suit automated code, as it can check if query returns 0 or
greater than 0 records.
For example, here's all roles that were granted to role 'Tom':
{code:java}
cassandra@cqlsh> list roles of 'tom';
role | super | login | options | datacenters
-------+-------+-------+---------+-------------
jane | True | False | {} | ALL
john | False | True | {} | ALL
smith | True | True | {} | ALL
tom | False | True | {} | ALL
(4 rows)
{code}
As you can see 'Tom' doesn't have direct superuser status.
We can acquire the knowledge of inherited status through:
{code:java}
cassandra@cqlsh> LIST ROLES OF 'tom' WITH SUPERUSER = true;
role | super | login | options | datacenters
-------+-------+-------+---------+-------------
jane | True | False | {} | ALL
smith | True | True | {} | ALL
(2 rows)
{code}
What do you think about such functionality?
P.S. Merge request contains filtering with options SUPERUSER and LOGIN only.
Parser can cope with query that contains "OPTIONS" and "DATACENTERS", as well.
I did not introduce new "options" rule, but connected an existing one from
query CREATE ROLE.
The last two options have no functional effect.
If someone would like to further tune LIST ROLES filtering with "datacenters"
or "options" in the future, they can bypass parser and start at java classes.
> List command output not correct for super user, after grant command
> -------------------------------------------------------------------
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
> Reporter: Shailaja Koppu
> Assignee: Maxim Chanturiay
> Priority: Normal
> Labels: lhf
> Fix For: 4.1.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> ----------------------------------------+-----------
> shaadmin1c1 | shaadmin1c1 | <table testk1.t1> | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> ------------------------------------------------------------------------------------------
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff0000}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
