[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17715055#comment-17715055
]
Maxim Chanturiay commented on CASSANDRA-18018:
----------------------------------------------
[~samt] I've throughly searched the web regarding definitions for "permission"
and "superuser privilege".
First of all, I did not fully grasp that they are not the same "tool" and each
one is intended for a different case.
I am sorry for wasting our time here :(.
I'll close my pull request as it doesn't make sense to couple between distinct
concepts ¯\_(ツ)_/¯
[~skoppu] I've looked over the way database team is managing superuser
privilege for roles at my place of work.
Our developers and customers (which can be looked as typical users) do not find
themselves interacting with superuser roles in any shape or form.
It is actually a security breach when such a role is gone outside of the
database team premises.
And database team members are fully aware of the superuser privilege
capabilities. They do not need a command to point that out - they know ahead
what role has it (even before connecting to the database).
> 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]
