[
https://issues.apache.org/jira/browse/CASSANDRA-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14179972#comment-14179972
]
Sylvain Lebresne commented on CASSANDRA-8163:
---------------------------------------------
bq. extra filtering out the results (like removing things the client isn't
supposed to see from SELECT * FROM system.schema_keyspaces resultset)
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)')}}).
bq. I'd rather wait for a proper solution
I don't know, I'd never heard anything about us going into cql-row-leve
authorization so at best it's an hypothetical solution and a far in the future
one. At the very least I think it's reasonable to keep this open a bit and see
if someone want to give this a shot. Happy to be clear that "we reserve
ourselves the right to not commit this if rewriting queries turns out to be too
messy".
> 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)
