[
https://issues.apache.org/jira/browse/CASSANDRA-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14188208#comment-14188208
]
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: https://issues.apache.org/jira/browse/CASSANDRA-8163
> 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
(v6.3.4#6332)
