[
https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14662586#comment-14662586
]
Paulo Motta commented on CASSANDRA-9927:
----------------------------------------
bq. {{CREATE}} is not a table-level permission, so you should change {{CREATE
MV}} to require {{SELECT}} on the table and {{CREATE}} on the keyspace.
Really? I saw in this
[doc|http://docs.datastax.com/en/cql/3.1/cql/cql_reference/list_permissions_r.html]
{{CREATE}} being listed as a table permission. If it's really forbidden,
shouldn't we rethink that for MVs ? It allows for a more fine-grained
authorization, since you may want to allow creation of MVs of a given table,
but not on the whole keyspace.
bq. More importantly, you should alter SelectStatement to check for {{SELECT}}
on the base table.
How can I miss that? My filtering algorithm for implementing the policies was
statement.contains("MATERIALIZED VIEW"). Will fix that in v2.
> Security for MaterializedViews
> ------------------------------
>
> Key: CASSANDRA-9927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9927
> Project: Cassandra
> Issue Type: Task
> Reporter: T Jake Luciani
> Assignee: Paulo Motta
> Labels: materializedviews
> Fix For: 3.0 beta 1
>
>
> We need to think about how to handle security wrt materialized views. Since
> they are based on a source table we should possibly inherit the same security
> model as that table.
> However I can see cases where users would want to create different security
> auth for different views. esp once we have CASSANDRA-9664 and users can
> filter out sensitive data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
