cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Brown (Jira)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-16910) DROP permission behavior does not match documentation
Date Thu, 02 Sep 2021 00:15:00 GMT
James Brown created CASSANDRA-16910:
---------------------------------------

             Summary: DROP permission behavior does not match documentation
                 Key: CASSANDRA-16910
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16910
             Project: Cassandra
          Issue Type: Bug
            Reporter: James Brown


There seems to be a mismatch between the documentation and reality with respect to the DROP
permission.

Specifically, the matrix in [the documentation|https://cassandra.apache.org/doc/4.0/cassandra/cql/cql_singlefile.html#permissions]
says that you can only {{DROP KEYSPACE}} if you have the {{DROP}} permission on {{ALL KEYSPACES}};
however, in testing, it appears that you can drop a keyspace if you merely have the {{DROP}}
permission on that keyspace itself.

I believe this is a documentation error; for example, having {{ALTER}} permission on a keyspace
is documented to let a role alter the keyspace itself in addition to altering tables within
it. I don't particularly like this behavior and would prefer to have a way to grant roles
the ability to alter/drop/create all objects within a keyspace without altering the keyspace
itself.

Demo on a stock cassandra.yaml with the only changes being setting {{authenticator}} to {{PasswordAuthenticator}}
and {{authorizer}} to {{CassandraAuthorizer}}:

{code}
$ ./bin/cqlsh -u cassandra -p cassandra
Connected to Bug Report Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 4.0.0 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cassandra@cqlsh> CREATE KEYSPACE demo_keyspace WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cassandra@cqlsh> CREATE ROLE nonsuper WITH PASSWORD='nonsuper' AND LOGIN=true;
cassandra@cqlsh> GRANT DROP on KEYSPACE demo_keyspace TO nonsuper;
cassandra@cqlsh> 

 $ ./bin/cqlsh -u nonsuper -p nonsuper
Connected to Bug Report Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 4.0.0 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
nonsuper@cqlsh> DROP KEYSPACE demo_keyspace;
nonsuper@cqlsh> CREATE KEYSPACE foo WITH replication = {'class': 'SimpleStrategy', 'replication_factor':
1};
Unauthorized: Error from server: code=2100 [Unauthorized] message="User nonsuper has no CREATE
permission on <all keyspaces> or any of its parents"
nonsuper@cqlsh> DROP KEYSPACE foo;
Unauthorized: Error from server: code=2100 [Unauthorized] message="User nonsuper has no DROP
permission on <keyspace foo> or any of its parents"
nonsuper@cqlsh>
{code}

Given the documented state that {{DROP KEYSPACE}} requires the {{DROP}} permission on {{ALL
KEYSPACES}}, I would expect the cal to {{DROP KEYSPACE demo_keyspace}} to fail with a 2100
error.

Two things that seem like action item to me:

* The documentation should be updated to indicate that having the {{DROP}} permission on a
keyspace allows you to {{DROP KEYSPACE}} and {{DROP TABLE in <keyspace>}}
* It sure would be swell if one could do something like {{GRANT DROP ON ALL TABLES IN KEYSPACE
<ks> TO <role>}} in order to avoid this whole issue (the way we can already grant
on {{ALL FUNCTIONS IN KEYSPACE <ks>}})...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message