[
https://issues.apache.org/jira/browse/CASSANDRA-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14179982#comment-14179982
]
Aleksey Yeschenko commented on CASSANDRA-8163:
----------------------------------------------
bq. We won't have to filter the result if we make sure the query itself don't
fetch anything the user is not supposed to. And while I'm not volonteering to
doing it, doing such restriction don't seem that complicated (for SELECT * FROM
system.schema_keyspaces, you'll transform it into SELECT * FROM
system.schema_keyspaces WHERE keyspace_name IN ('allowed_keyspace(user)')).
Yes for keyspaces, more involved for columns and columnfamilies (need IN both
on the partition key and the first clustering column).
But we can keep it open if you insist ¯\_(ツ)_/¯
> 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
>
> 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)
