[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17715755#comment-17715755
]
Shailaja Koppu commented on CASSANDRA-18018:
--------------------------------------------
Let's assume we have a service which interacts with C* using list permissions
command to retrieve permissions of a user on a given keyspace/table and then
that service performs operations accordingly. This use case will break because
list permissions command behaves differently for superusers.
I understand the complexity involved in getting this command output right. I
like to have this command somehow indicate that given user is a super user, or
indicate that given user has all permissions. That way external services which
are interacting with C* don't have to make two trips, first to check is this a
superuser, then to check permissions for non-superusers.
Not only for this use case, even in general would be great if this command
simply says given user is a superuser. That way caller can simply assume all
permissions by seeing 'superuser' tag.
I am discussing with [~samt] offline regarding this use case, will get back to
you soon.
> 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
> Priority: Normal
> Labels: lhf
> Fix For: 4.1.x
>
> Time Spent: 0.5h
> 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]
