cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
Date Fri, 07 Aug 2015 22:40:47 GMT


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|]
{{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

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:
>             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

View raw message