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 by Carl Yeksigian on
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
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?
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).
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.