cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
Date Thu, 30 Jul 2015 10:59:07 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14647471#comment-14647471
] 

Sam Tunnicliffe commented on CASSANDRA-9927:
--------------------------------------------

h6. Separating view permissions from the base table
It makes sense to me for the grants on an MV to be independent of the base table, for the
reasons [suggested by| https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14646639&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14646639]
by [~carlyeks] on CASSANDRA-6477 :

bq. it's possible for a less restrictive set of values to be present in the MV, so the set
of permissions should be accordingly more granular.

particularly in light of CASSANDRA-9664.

h6. Applicable/Valid permissions for views

Also on #6477, there's some discussion around {{MODIFY}} permissions; my $0.02 there is that
{{MODIFY}} shouldn't even be applicable to MV's. Much like secondary indexes, these are system
maintained and direct modification is not/should not be possible (possibly only {{truncate}}
should be supported - CASSANDRA-8082?). Counterfactually, what would be the implication of
a role with {{MODIFY}} on the base table, but not the MV?

h6. Resource hierarchy

MVs could be bundled together with Tables as {{DataResources}} within a keyspace. From this
it would follow that {{GRANT <permission> ON <keyspace> TO <role>}} would
apply to all current & future tables *and* views in the keyspace, meaning we lose the
ability to distinguish between them when operating at the keyspace level. This probably isn't
a issue for DML, but maybe more so for DDL. i.e. It's probably ok for a role with {{SELECT}}
at the keyspace level to be able to read from all tables *and* views, but would we want to
be more granular about {{CREATE TABLE}} and {{CREATE MATERIALIZED VIEW}}?

When we're not working at the keyspace level, just adding a new {{MATERIALIZED_VIEW}} level
in {{DataResource}} would enable a specific view to be referenced in a grant statement (with
a minor syntax tweak) {{GRANT <permission> ON VIEW <view> TO <role>}}. A
new level would also make it easy to apply appropriate perms to views when using {{ALL}}.
e.g. if we agree that {{MODIFY}} shouldn't be valid on a view then this would enable it to
be omitted when doing {{GRANT ALL ON VIEW <view> TO <role>}}. 

The alternative approach is to have a new {{IResource}} implementation & hierarchy for
views. There would probably be a bit of duplication between this and {{DataResource}}, but
the main benefit would be to provide a container level resource just for views, enabling statements
like {{GRANT <permission> TO ALL VIEWS IN KEYSPACE <keyspace> TO <role>}}.
The ability to act on the collections of views and tables for a keyspace independently, rather
than lumping them together. In this case, we'd be able to separate DDL permissions on tables
& views, if that's a goal.

If we were to go down this route, we should probably make it more explicit that (legacy) statements
of the form {{GRANT <permission> ON KEYSPACE <keyspace> TO <role>}} apply
only to tables, and so change them to {{GRANT <permission> ON ALL TABLES IN KEYSPACE
<keyspace> TO <role>}} (and continue to support the original form but deprecate
it).

h6. Default permissions for view creator

One final comment, we should be automatically granting permissions on newly created views
to whoever creates them like we do with keyspaces, tables, roles, functions etc. This just
needs an override {{grantPermissionsToCreator}} in {{CreateMaterializedViewStatement}}.

> Security for MaterializedViews
> ------------------------------
>
>                 Key: CASSANDRA-9927
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9927
>             Project: Cassandra
>          Issue Type: Task
>            Reporter: T Jake Luciani
>             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)

Mime
View raw message