[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-18018:
----------------------------------------
Bug Category: Parent values: Correctness(12982)Level 1 values: API /
Semantic Definition(13162)
Complexity: Normal
Discovered By: User Report
Reviewers: Sam Tunnicliffe, Shailaja Koppu
Severity: Low
Status: Open (was: Triage Needed)
Thanks for the work so far [~maximc] In itself it's fine but this is missing at
least a couple of things and/or making the view inconsistent across different
queries.
It doesn't quite cover list queries where the resource is also specified. For
instance:
{code:java}
LIST ALL PERMISSIONS ON ks1.t1;
LIST ALL PERMISSIONS ON ks1.t1 OF user1;
LIST SELECT PERMISSION ON ks1.t1 OF user1
LIST SELECT, MODIFY PERMISSION ON ks1.t1 OF user1;
{code}
should add addition filters to the set of permissions returned, whether or not
the role has superuser status.
The current version also adds an inconsistency between
{code:java}
LIST ALL PERMISSIONS OF user1;{code}
which now does the inference of additional implied permissions if {{user1}} is
a superuser, and
{code:java}
LIST ALL PERMISSIONS;{code}
which does not (i.e. here, only the explicitly granted permissions are shown
for {{{}user1{}}};
There may be other issues or inconsistencies, but I didn't go any further yet.
Again, I'm wondering whether it's actually worth trying to satisfy all of these
edge cases for the sake of the {{LIST PERMISSIONS}} statement. I'll reiterate
that superuser status doesn't actually grant permissions, rather it causes all
permissions checks to be bypassed for the role in question, so I question
whether the increased complexity is necessary.
> 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: 10m
> 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]
