[ 
https://issues.apache.org/jira/browse/CASSANDRA-11305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15299940#comment-15299940
 ] 

Sam Tunnicliffe commented on CASSANDRA-11305:
---------------------------------------------

bq. Instead of modifying the default CQL behaviour and its semantic (like I 
suggested before) maybe this can be implemented throught cassandra.yaml?
maybe, but the Hive config lets you specify exactly which privileges to 
automatically grant. I think this is fine for Hive as it only applies to 
Databases and Tables, which share the same set of applicable privileges. This 
isn't the case in C* though with roles, functions, aggregations and jmx 
resources (although the latter are not created in the same way as other 
database objects). So if we were to adopt the Hive approach, you'd be 
specifying the superset of privileges from which the applicable subset could be 
automatically granted and TBH, this feels a bit messy to me. 

It might be more feasible to have a single toggle in the yaml to completely 
turn off auto granting on a system-wide basis. I did wonder whether a keyspace 
level property could work, but not all resources are keyspace-scoped (roles for 
instance). I'm not advocating for that system-wide solution btw, just saying 
that it seems potentially more straightforward in implementation and conceptual 
terms.

I don't see a huge demand for this feature either, so I would imagine it 
falling fairly low on the list of priorities I'm afraid, but if you want to 
submit a patch for it, please do.

> Customization of the auto granting process
> ------------------------------------------
>
>                 Key: CASSANDRA-11305
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11305
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: CQL
>         Environment: Apache Cassandra 3.3, cqlsh 5.0.1, CQL spec 3.4.0
>            Reporter: Alexandre Linte
>            Priority: Minor
>             Fix For: 3.3
>
>
> Hello,
> By default, Cassandra implements an auto granting process which is applied 
> when a USER | ROLE does a CREATE KEYSPACE, CREATE TABLE, CREATE FUNCTION, 
> CREATE AGGREGATE or CREATE ROLE statement. The creator is automatically 
> granted all applicable permissions on the new resource.
> For example, the ROLE "toto_user" is created and has CREATE permission on its 
> personal KEYSPACE "toto_keyspace". Today when toto_user create a TABLE, he is 
> automatically granted the following rights:
> * ALTER
> * DROP
> * SELECT
> * MODIFY
> * AUTHORIZE
> Moreover if you want to REVOKE a permission for "toto_user" on a table, this 
> table must exist.
> The idea of the issue is to improve the auto granting process. I thought 
> about a modification of the REVOKE and GRANT SQL commands. You can find below 
> the syntax part:
> {noformat}
> <grant-permission-stmt> ::= GRANT ( ALL ( PERMISSIONS )? | <permission> ( 
> PERMISSION )? ) ON <resource> TO <identifier>
> <permission> ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE | 
> DESRIBE | EXECUTE
> <resource> ::= ALL KEYSPACES
>               | KEYSPACE <identifier>
>               | ( TABLE )? <tablename>
>               | ALL ROLES
>               | ROLE <identifier>
>               | ALL FUNCTIONS ( IN KEYSPACE <identifier> )?
>               | FUNCTION <functionname>
> <automatic-granting> ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
> {noformat}
> {noformat}
> <revoke-permission-stmt> ::= REVOKE ( ALL ( PERMISSIONS )? | <permission> ( 
> PERMISSION )? ) ON <resource> FROM <identifier>
> <permission> ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE | 
> DESRIBE | EXECUTE
> <resource> ::= ALL KEYSPACES
>               | KEYSPACE <identifier>
>               | ( TABLE )? <tablename>
>               | ALL ROLES
>               | ROLE <identifier>
>               | ALL FUNCTIONS ( IN KEYSPACE <identifier> )?
>               | FUNCTION <functionname>
> <automatic-granting> ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
> {noformat}
> And now multiple the samples part:
> {noformat}
> GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user;
> => default functioning, when toto_user creates a table he will be 
> automatically granted all permissions.
> GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE 
> TABLE;
> => grant all permissions to the resource (table) created by toto_user on the 
> keyspace toto_keyspace.
> GRANT SELECT ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE TABLE;
> => grant select permission to the resource (table) created by toto_user on 
> the keyspace toto_keyspace.
> REVOKE ALL PERMISSIONS ON KEYSPACE toto_keyspace FROM toto_user;
> => default functioning, toto_user will not be able to do something on the 
> keyspace toto_keyspace.
> REVOKE AUTHORIZE PERMISSION ON KEYSPACE toto_keyspace FROM toto_user WHEN 
> CREATE TABLE;
> => revoke authorize permission to the resource (table) created by toto_user 
> on the keyspace toto_keyspace.
> REVOKE DROP PERMISSION ALL KEYSPACES FROM toto_user WHEN CREATE ROLE;
> => revoke drop permission to the resource (role) created by toto_user on the 
> keyspace toto_keyspace.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to