DataStax Support Forums » Topic: GRANT and REVOKE explanation for CQL3 (cassandra 1.2.0)

DataStax Support Forums » Topic: GRANT and REVOKE explanation for CQL3 (cassandra 1.2.0) http://www.datastax.com/support-forums/topic/grant-and-revoke-explanation-for-cql3-cassandra-120 Software, Support, and Training for Apache Cassandra en-US Thu, 20 Jun 2013 07:49:02 +0000 http://bbpress.org/?v=1.0.3 <![CDATA[Search]]> q http://www.datastax.com/support-forums/search.php khahn on "GRANT and REVOKE explanation for CQL3 (cassandra 1.2.0)" http://www.datastax.com/support-forums/topic/grant-and-revoke-explanation-for-cql3-cassandra-120#post-8506 Fri, 18 Jan 2013 23:39:51 +0000 khahn 8506@http://www.datastax.com/support-forums/ Sorry for the delay and that you were inconvenienced by the outdated material. GRANT PERMISSIONS Provides users access to database objects. GRANT ALL| ALL PERMISSIONS permission_name PERMISSION ON resource TO user WITH GRANT OPTION (there are options in this syntax that don't copy over) permission_name is one of these: ALL ALL PERMISSIONS ALTER AUTHORIZE CREATE DROP FULL_ACCESS MODIFY NO_ACCESS SELECT resource is one of these: ALL KEYSPACES KEYSPACE keyspace_name TABLE keyspace_name.table_name Description Permissions to access all keyspaces, a named keyspace, or a table can be granted to a user. This table lists the permissions needed to use cqlsh statements: Permission cqlsh Statements ALTER ALTER KEYSPACE, ALTER TABLE, CREATE INDEX, DROP INDEX AUTHORIZE GRANT, REVOKE CREATE CREATE KEYSPACE, CREATE TABLE DROP DROP KEYSPACE, DROP TABLE MODIFY INSERT, DELETE, UPDATE, TRUNCATE SELECT SELECT The authorize permission gives a user the ability to grant access with the grant option, not just grant permissions to other users. Currently granting permissions on indexes and configuration options are not available at this time. Examples Give 'bashful' permission to perform SELECT queries on all tables in all keyspaces: GRANT SELECT ON ALL KEYSPACES TO bashful; Give 'dopey' permission to perform INSERT, UPDATE, DELETE and TRUNCATE queries on all tables in the 'woods' keyspace: GRANT MODIFY ON KEYSPACE woods TO dopey; Give 'doc' permission to perform ALTER KEYSPACE queries on the 'mines' keyspace, and also ALTER TABLE, CREATE INDEX and DROP INDEX queries on all tables in 'mines' keyspace: GRANT ALTER ON KEYSPACE mines TO doc; Give 'doc' permission to run all types of queries on cottage.chores table: GRANT ALL PERMISSIONS ON cottage.chores TO doc; SELECT permission Permissions checks are recursive: To be able to perform SELECT queries on ‘my_table’ you have to have SELECT permission on the table OR on its parent keyspace OR on ALL KEYSPACES. CREATE permission To be able to CREATE TABLE you need CREATE permission on its parent keyspace or ALL KEYSPACES. etc. To be able to CREATE KEYSPACE you need CREATE permission on ALL KEYSPACES. GRANT, REVOKE, and LIST To grant access to a keyspace to just one user, assuming nobody else has ALL KEYSPACES access, you use this statement: GRANT ALL ON KEYSPACE keyspace_name TO user_name GRANT, REVOKE and LIST check for table/keyspace existence before execution. GRANT and REVOKE check for user existence after IAuthenticator rewrite is complete. REVOKE PERMISSIONS REVOKE ALL| ALL PERMISSIONS permission_name PERMISSION ON resource FROM user_name permission_name is one of these: ALL ALL PERMISSIONS ALTER AUTHORIZE CREATE DROP FULL_ACCESS MODIFY NO_ACCESS SELECT resource is one of these: ALL KEYSPACES KEYSPACE keyspace_name TABLE keyspace_name.table_name Description Permissions to access all keyspaces, a named keyspace, or a table can be revoked from a user. This table lists the permissions needed to use cqlsh statements: Permission cqlsh Statements ALTER ALTER KEYSPACE, ALTER TABLE, CREATE INDEX, DROP INDEX AUTHORIZE GRANT, REVOKE CREATE CREATE KEYSPACE, CREATE TABLE DROP DROP KEYSPACE, DROP TABLE MODIFY INSERT, DELETE, UPDATE, TRUNCATE SELECT SELECT Example REVOKE SELECT ON cottage.chores FROM doc; The user doc can no longer perform SELECT queries on the cottage.chores table. sarch on "GRANT and REVOKE explanation for CQL3 (cassandra 1.2.0)" http://www.datastax.com/support-forums/topic/grant-and-revoke-explanation-for-cql3-cassandra-120#post-8458 Wed, 16 Jan 2013 16:10:42 +0000 sarch 8458@http://www.datastax.com/support-forums/ khahn, thanks for the info, but unfortunately I've already found those pages. The datastax blog about dynamic permissions is out of date now with 1.2.0 ('GRANT FULL_ACCESS ...'; 'LIST GRANTS ...'; and 'GRANT UPDATE ON ks' all don't work). And as you've discovered, the official 1.2 documentation don't mention GRANT and the CQL3 spec mentions that they are keywords, but do not have any more information on how to use them. I was hoping that there would be some internal documentation or mailings that would shed some light on the issue. At the moment I'm having to bastardise the code to make it fit what it says it should do. khahn on "GRANT and REVOKE explanation for CQL3 (cassandra 1.2.0)" http://www.datastax.com/support-forums/topic/grant-and-revoke-explanation-for-cql3-cassandra-120#post-8411 Mon, 14 Jan 2013 18:55:38 +0000 khahn 8411@http://www.datastax.com/support-forums/ I found an explanation of how GRANT/REVOKE is supposed to work in cassandra >= 1.2.0, but have not actually tried this: <a href="http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1" rel="nofollow">http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1</a> The official DataStax 1.2 docs do not include information about GRANT/REVOKE. Authentication and authorization are briefly covered in <a href="http://www.datastax.com/docs/1.2/configuration/authentication" rel="nofollow">http://www.datastax.com/docs/1.2/configuration/authentication</a>. Hope this helps. sarch on "GRANT and REVOKE explanation for CQL3 (cassandra 1.2.0)" http://www.datastax.com/support-forums/topic/grant-and-revoke-explanation-for-cql3-cassandra-120#post-8403 Mon, 14 Jan 2013 14:13:31 +0000 sarch 8403@http://www.datastax.com/support-forums/ I'm trying to implement an internal Cassandra-as-a-service and want to use the permissions/authorization in CQL3 to implement this. Is there any explanation of how GRANT/REVOKE is supposed to work in cassandra >= 1.2.0? I've played around with it a bit, but it can only be done at the column-family (/table) level. I can't find a way of applying GRANT privileges on an entire keyspace or inherit them for new column families that are created. Does anyone know how they are supposed to function?