DataStax Support Forums » User Favorites: sarch

DataStax Support Forums » User Favorites: sarch sarch Software, Support, and Training for Apache Cassandra en-US Thu, 23 May 2013 09:24:14 +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? sarch on "Cassandra Client authentication encryption" http://www.datastax.com/support-forums/topic/cassandra-client-authentication-encryption#post-8278 Fri, 04 Jan 2013 12:16:24 +0000 sarch 8278@http://www.datastax.com/support-forums/ As I understand it, Cassandra offers you the opportunity to implement the two interfaces: org.apache.cassandra.auth.IAuthenticator.java org.apache.cassandra.auth.IAuthority.java to allow for authentication and that you extend these interfaces. A simple example (not secure) implementation exists in the source code that can be used. But as I understand it, the IAuthenticator-extended class gets the credentials from the client in a map containing plaintext "username" and "password" fields. As communication to port 9160 is not encrypted, this means that even if you implement a secure class for the IAuthenticator and IAuthority interfaces, your password from your client will be sent in plaintext and is vulnerable to snooping. Have I got my understanding of this situation correct and is there any way of securing your password as it is sent across the network to authorise your cassandra session without tunnelling it through an SSH session? tycen-medio on "Different versions in a cassandra ring." http://www.datastax.com/support-forums/topic/different-versions-in-a-cassandra-ring#post-7838 Wed, 05 Dec 2012 18:45:58 +0000 tycen-medio 7838@http://www.datastax.com/support-forums/ I'm not an expert on this, but it worked fine for us short term to have different versions in the same ring. I just upgraded 10 nodes from 0.7.9 to 1.1.6 and had the ring online while I did it - upgrading one node at a time. You should also be able to do your plan of adding 6 new nodes with the new version then decommissioning the 6 old nodes. I think the bigger issue to look out for is any incompatibility issues between the versions your on and targeting. This page had a good list of changes between versions - read the "upgrading" section of each version between your current version and your target version to make sure there isn't anything that will cause trouble: <a href="https://github.com/apache/cassandra/blob/trunk/NEWS.txt" rel="nofollow">https://github.com/apache/cassandra/blob/trunk/NEWS.txt</a> Good luck. nickmbailey on "nodetool snapshot not taking snapshots" http://www.datastax.com/support-forums/topic/nodetool-snapshot-not-taking-snapshots#post-7779 Mon, 03 Dec 2012 18:49:58 +0000 nickmbailey 7779@http://www.datastax.com/support-forums/ Its hard to know what could be going wrong in that case. My advice would be to check the cassandra log for errors after you run a snapshot command. sarch on "nodetool snapshot not taking snapshots" http://www.datastax.com/support-forums/topic/nodetool-snapshot-not-taking-snapshots#post-7772 Mon, 03 Dec 2012 14:39:17 +0000 sarch 7772@http://www.datastax.com/support-forums/ Yes, I'm definitely calling it on each node in the cluster, and yes, they all have >10GB of data. nickmbailey on "nodetool snapshot not taking snapshots" http://www.datastax.com/support-forums/topic/nodetool-snapshot-not-taking-snapshots#post-7736 Fri, 30 Nov 2012 16:41:27 +0000 nickmbailey 7736@http://www.datastax.com/support-forums/ You are calling nodetool snapshot on each node in the cluster? Also are you sure that all nodes have data? sarch on "Different versions in a cassandra ring." http://www.datastax.com/support-forums/topic/different-versions-in-a-cassandra-ring#post-7731 Fri, 30 Nov 2012 09:49:48 +0000 sarch 7731@http://www.datastax.com/support-forums/ I'm new to cassandra. How will a cluster handle nodes that are running different versions of cassandra? ie, will a cluster with nodes that are running both 1.0.11 and 1.0.12 work happily together. I would *assume* so but can't find information on the subject. Similarly, what about 1.1.5 and 1.1.6. And what about running 1.0.12 and 1.1.5 together. Obviously this is not an idea situation but would like to know what happens in this situation. I'm running a cluster in AWS and need to migrate to a newer version of cassandra. For repeatability we just launch a different AMI with the new version of cassandra installed on it. So if I have 6 nodes with cassandra 1.0.12 on it, is it a sensible migration strategy to launch 6 new nodes with cassandra 1.1.6 on them, join the ring (so it's got a total of 12 nodes), then decommission the original 6? Or is it best to manually upgrade the original cluster to 1.1.6, then do the same migration pattern (add new nodes to get cluster of 12, then decommission the old nodes). sarch on "nodetool snapshot not taking snapshots" http://www.datastax.com/support-forums/topic/nodetool-snapshot-not-taking-snapshots#post-7730 Fri, 30 Nov 2012 09:44:21 +0000 sarch 7730@http://www.datastax.com/support-forums/ I've never taken a snapshot before, so I may be doing something wrong, but I can't seem to take snapshots of my cluster. It's got 6 nodes, and issuing 'nodetool -h localhost snapshot' or 'nodetool -h localhost snapshot MyKeySpace' seems to work on the first node in the ring, but not on the others. All processes exit with "Snapshot directory: 1354267525967" etc, but when I try to find the snapshot directory with 'find /path/to/my/cassandra/data/dir -name snapshots' it only finds a directory on the first node, not on any others. Due to some slightly complicated reasoning, my cluster is running 1.0.11 on nodes 1 and 2, but 1.0.12 on nodes 3-6. I assumed that this would not cause a problem but am trying to upgrade to 1.1.6 on all nodes without losing data, so want to take a snapshot first. Thanks.