[ https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649049#comment-17649049 ]
Maxim Chanturiay commented on CASSANDRA-18018: ---------------------------------------------- [~skoppu] [~samt] Hello! I have some initial results and would like your opinion regarding a couple of questions. Actually, I really need an advice at this stage. :) The naive approach was to go over the all the *resources* that Cassandra has to offer and map them to relevant {*}permissions{*}. {+}Possible Permissions{+}: CREATE, ALTER, DROP, SELECT, MODIFY, AUTHORIZE, DESCRIBE, EXECUTE. {+}Possible Resources{+}: DATA ({_}keyspaces{_}, _tables_ and {_}views{_}), ROLE, FUNCTION, MBEAN. An example of an output for _ALL PERMISSIONS_ on {_}ALL RESOURCES{_}: {code:java} cassandra@cqlsh> LIST ALL PERMISSIONS OF superuser_a; @ Row 1 ------------+--------------------------------------------------------- role | superuser_a username | superuser_a resource | <keyspace keyspace_a> permission | CREATE @ Row 2 ------------+--------------------------------------------------------- role | superuser_a username | superuser_a resource | <keyspace keyspace_a> permission | ALTER ... more rows ... @ Row 929 ------------+--------------------------------------------------------- role | superuser_a username | superuser_a resource | <function system.now()> permission | EXECUTE ... more rows ... @ Row 970 ------------+--------------------------------------------------------- role | superuser_a username | superuser_a resource | <role superuser_joe> permission | DESCRIBE (970 rows) {code} _First question - does the solution make sense?_ I know it is a very broad question. But if you wanted to see all permissions for a super user, would the above output suffice? _Second question - could you advise on approach to get all MBEANS?_ For example, keyspace has kindly prepared metadata class that provides the list off all tables and views. I have failed to find so far something that groups all MBEANS (if such functionality makes sense). The only solution I could think of is managing a constant list of all classes with an attribute {_}MBEAN_NAME{_}. > 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 > > 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org