cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8163) Complete restriction of a user to given keyspace
Date Wed, 29 Oct 2014 10:14:34 GMT


Sylvain Lebresne commented on CASSANDRA-8163:

bq. is this some thing doable in 2.0.X?

Provided we keep the restriction to the keyspace level initially (that is, within a keyspace,
a user can't see only some tables and not others), enforcing the restriction should be reasonably
trivial technically (since all schema tables use the keyspace name as partition key). That
said, we'd need a new type of permission and there is potentially backward compatibility concerns
which might be the real blocker for a pre-3.0 commit. And for 2.0, we're in the "fix bugs
only" phase at this point, so at best this could be 2.1 (provided again there is no strong
backward compatibility issues, which I haven't checked because I'm not 100% up to date on
authorization stuffs).

> Complete restriction of a user to given keyspace
> ------------------------------------------------
>                 Key: CASSANDRA-8163
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Vishy Kasar
>            Priority: Minor
> We have a cluster like this:
> project1_keyspace
> table101
> table102
> project2_keyspace
> table201
> table202
> We have set up following users and grants:
> project1_user has all access to project1_keyspace 
> project2_user has all access to project2_keyspace
> However project1_user can still do a 'describe schema' and get the schema for project2_keyspace
as well. We do not want project1_user to have any knowledge for project2 in any way (cqlsh/java-driver
etc) .

This message was sent by Atlassian JIRA

View raw message