[
https://issues.apache.org/jira/browse/CASSANDRA-16910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17408782#comment-17408782
]
Brandon Williams commented on CASSANDRA-16910:
----------------------------------------------
You should probably file these as separate issues for better traction - one to
fix docs, and one to change behavior. This one looks like it will fit best in
the first category.
> 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
> Priority: Normal
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
