[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[
https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680203#comment-14680203
]
Aleksey Yeschenko commented on CASSANDRA-9927:
--
{{CreateMaterializedViewStatement}} should only require {{ALTER}} on the baste
table, so should {{DropMaterializedViewStatement}}. Mimic {{CREATE INDEX}} and
{{DROP INDEX}}.
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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[
https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680296#comment-14680296
]
Paulo Motta commented on CASSANDRA-9927:
Updated branches with suggested modifications:
* [3.0 patch|https://github.com/pauloricardomg/cassandra/tree/9927-3.0]
* [trunk patch|https://github.com/pauloricardomg/cassandra/tree/9927-trunk]
Updated policies:
* {{CREATE MATERIALIZED VIEW}}: {{ALTER}} permissions on base table or parent
keyspace.
* {{ALTER MATERIALIZED VIEW}}: {{ALTER}} permission on base table or parent
keyspace.
* {{DROP MATERIALIZED VIEW}}: {{ALTER}} permission on base table or parent
keyspace.
* {{SELECT}}: {{SELECT}} permissions on base table or parent keyspace.
Tests will be available shortly on the following links:
* [3.0
dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-3.0-dtest/]
* [3.0
testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-3.0-testall/]
* [trunk
dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-trunk-dtest/]
* [trunk
testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-trunk-testall/]
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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680758#comment-14680758 ] Aleksey Yeschenko commented on CASSANDRA-9927: -- My apologies. I didn't notice the other 2 commits in the branch. Really my bad. I can commit as is, or, if you don't mind migrating tests to dtest, wait till then. 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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680875#comment-14680875 ] Paulo Motta commented on CASSANDRA-9927: Updated branches with suggested modifications: * [3.0 patch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:9927-3.0] * [trunk patch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:9927-trunk] Materialized views authentication dtests available here: [PR451|https://github.com/riptano/cassandra-dtest/pull/451] When ready, tests will be available here: * [3.0 dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-3.0-dtest/] * [3.0 testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-3.0-testall/] * [trunk dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-trunk-dtest/] * [trunk testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-trunk-testall/] 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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680941#comment-14680941 ] Aleksey Yeschenko commented on CASSANDRA-9927: -- Committed as [1a9286c07a5c168df677da9d6be7178d087ea005|https://github.com/apache/cassandra/commit/1a9286c07a5c168df677da9d6be7178d087ea005] to cassandra-3.0 and merged into trunk, thanks. 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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[
https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680714#comment-14680714
]
Aleksey Yeschenko commented on CASSANDRA-9927:
--
This is the desired logic, thank you.
That said, it doesn't build when applied to current cassandra-3.0 (can you fix
and rebase?)
Also the tests don't build. {{CQLAuthTester}} is missing, and, in general,
{{MaterializedViewAuthorizationTest}} doesn't belong where it was put.
All auth test currently belong to dtests,
[here|https://github.com/riptano/cassandra-dtest/blob/master/auth_test.py]. Can
you please convert the tests to dtests, where the other auth tests are?
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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[
https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662676#comment-14662676
]
Paulo Motta commented on CASSANDRA-9927:
Updated branches with suggested modifications:
* [3.0 patch|https://github.com/pauloricardomg/cassandra/tree/9927-3.0]
* [trunk patch|https://github.com/pauloricardomg/cassandra/tree/9927-trunk]
Updated policies:
* {{CREATE MATERIALIZED VIEW}}: {{ALTER}} and {{SELECT}} permissions on base
table or parent keyspace.
* {{ALTER MATERIALIZED VIEW}}: {{ALTER}} permission on base table or parent
keyspace.
* {{DROP MATERIALIZED VIEW}}: {{DROP}} permission on base table or parent
keyspace.
* {{SELECT}}: {{SELECT}} permissions on base table or parent keyspace.
Tests will be available shortly on the following links:
* [3.0
dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-3.0-dtest/]
* [3.0
testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-3.0-testall/]
* [trunk
dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-trunk-dtest/]
* [trunk
testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-trunk-testall/]
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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[
https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662556#comment-14662556
]
Paulo Motta commented on CASSANDRA-9927:
Finished initial implementation of materialized views authentication. 3.0 v1
patch is available
[here|https://github.com/pauloricardomg/cassandra/tree/9927-3.0] for review.
In this initial implementation, the following permissions are necessary for
each operation:
* {{CREATE MATERIALIZED VIEW}}: {{CREATE}} and {{SELECT}} permissions on base
table or parent keyspace.
* {{ALTER MATERIALIZED VIEW}}: {{ALTER}} permission on base table or parent
keyspace.
* {{DROP MATERIALIZED VIEW}}: {{DROP}} permission on base table or parent
keyspace.
Tests will be available shortly on the following links:
* [3.0
dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-3.0-dtest/]
* [3.0
testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-3.0-testall/]
* [trunk
dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-trunk-dtest/]
* [trunk
testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9927-trunk-testall/]
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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[
https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[
https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662567#comment-14662567
]
Aleksey Yeschenko commented on CASSANDRA-9927:
--
{{CREATE}} is not a table-level permission, so you should change {{CREATE MV}}
to require {{SELECT}} on the table and {{CREATE}} on the keyspace.
More importantly, you should alter {{SelectStatement}} to check for {{SELECT}}
on the base table.
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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[
https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662600#comment-14662600
]
Aleksey Yeschenko commented on CASSANDRA-9927:
--
The doc is for 2.0 and 2.1, it says so in the title. In 2.2 and 3.0 that is no
longer true.
What base permissions we should require for {{CREATE MV}} is the only minor
detail I'm not certain about. Maybe we should just treat them as indexes for
now and require {{ALTER}} on the base table for both {{CREATE MV}} and {{DROP
MV}}. [~beobal] ?
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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662609#comment-14662609 ] Sam Tunnicliffe commented on CASSANDRA-9927: bq.Maybe we should just treat them as indexes for now sgtm for now 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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661378#comment-14661378 ] Aleksey Yeschenko commented on CASSANDRA-9927: -- bq. So let's go with the latter. +1 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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660048#comment-14660048 ] T Jake Luciani commented on CASSANDRA-9927: --- I don't think they inherit the base tables permissions currently. I would be trivial to add the current role to the MV at the time of MV creation. However it's not clear if you want the role pinned so any changes to the base affect the view. That would go against the let users add different roles for different views. Security for MaterializedViews -- Key: CASSANDRA-9927 URL: https://issues.apache.org/jira/browse/CASSANDRA-9927 Project: Cassandra Issue Type: Task Reporter: T Jake Luciani 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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660201#comment-14660201 ] Jonathan Ellis commented on CASSANDRA-9927: --- I'm happy with leaving MV permissions explicity. Inheriting base permissions is definitely not the right thing in all situations. NB: Aleksey pointed out that we do to require SELECT on the base table when CREATEing an MV. Security for MaterializedViews -- Key: CASSANDRA-9927 URL: https://issues.apache.org/jira/browse/CASSANDRA-9927 Project: Cassandra Issue Type: Task Reporter: T Jake Luciani 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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[
https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660212#comment-14660212
]
Aleksey Yeschenko commented on CASSANDRA-9927:
--
Requiring {{SELECT}} on the base table for CREATE MV is what the initial
implementation did - I'm not sure that it's the right thing to do, or
sufficient.
I'm actually leaning towards validating all permissions against the base table
- treat them like slightly more visible indexes. For v1.
Security for MaterializedViews
--
Key: CASSANDRA-9927
URL: https://issues.apache.org/jira/browse/CASSANDRA-9927
Project: Cassandra
Issue Type: Task
Reporter: T Jake Luciani
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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660218#comment-14660218 ] Jonathan Ellis commented on CASSANDRA-9927: --- I'm okay with either require explicit grants or always validate against base table for 3.0. Security for MaterializedViews -- Key: CASSANDRA-9927 URL: https://issues.apache.org/jira/browse/CASSANDRA-9927 Project: Cassandra Issue Type: Task Reporter: T Jake Luciani 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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658812#comment-14658812 ] Jonathan Ellis commented on CASSANDRA-9927: --- Why can't we just inherit base table permissions for 3.0? Security for MaterializedViews -- Key: CASSANDRA-9927 URL: https://issues.apache.org/jira/browse/CASSANDRA-9927 Project: Cassandra Issue Type: Task Reporter: T Jake Luciani 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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658990#comment-14658990 ] Aleksey Yeschenko commented on CASSANDRA-9927: -- bq. Why can't we just inherit base table permissions for 3.0? That was the initial suggestion, still in CASSANDRA-6477 comments. Jake raised a valid point that a user might want to grant access to the view that is a subset of the columns in the base to more users (if a view doesn't have anything sensitive, but the base table does). What do we want to do in the long term? Security for MaterializedViews -- Key: CASSANDRA-9927 URL: https://issues.apache.org/jira/browse/CASSANDRA-9927 Project: Cassandra Issue Type: Task Reporter: T Jake Luciani 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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659028#comment-14659028 ] Jonathan Ellis commented on CASSANDRA-9927: --- Long term, we do want to support this. But it's pretty late to start design for 3.0. Security for MaterializedViews -- Key: CASSANDRA-9927 URL: https://issues.apache.org/jira/browse/CASSANDRA-9927 Project: Cassandra Issue Type: Task Reporter: T Jake Luciani 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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659089#comment-14659089 ] Aleksey Yeschenko commented on CASSANDRA-9927: -- [~tjake] [~carlyeks] actually, how is the ticket description different from what's already in trunk? Security for MaterializedViews -- Key: CASSANDRA-9927 URL: https://issues.apache.org/jira/browse/CASSANDRA-9927 Project: Cassandra Issue Type: Task Reporter: T Jake Luciani 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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[
https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=14646639page=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)
[jira] [Commented] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14646736#comment-14646736 ] Jack Krupansky commented on CASSANDRA-9927: --- The CQL.textile for MV still shows parentheses being required around the selection list, which is not the case in SELECT. 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)
