[
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)
