Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9D180184B7 for ; Thu, 30 Jul 2015 10:59:07 +0000 (UTC) Received: (qmail 14013 invoked by uid 500); 30 Jul 2015 10:59:07 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 13979 invoked by uid 500); 30 Jul 2015 10:59:07 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 13962 invoked by uid 99); 30 Jul 2015 10:59:07 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Jul 2015 10:59:07 +0000 Date: Thu, 30 Jul 2015 10:59:07 +0000 (UTC) From: "Sam Tunnicliffe (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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 ON TO }} 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 ON VIEW TO }}. 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 TO }}. 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 TO ALL VIEWS IN KEYSPACE TO }}. 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 ON KEYSPACE TO }} apply only to tables, and so change them to {{GRANT ON ALL TABLES IN KEYSPACE TO }} (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)