[
https://issues.apache.org/jira/browse/CASSANDRA-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14266101#comment-14266101
]
Sam Tunnicliffe commented on CASSANDRA-8303:
--------------------------------------------
It seems to me that this could be a reasonably natural fit as an extension to
the existing authz system. If we do go down that route there are a couple of
things to consider.
What we're really talking about here are restrictions on the permissions a
particular user may have been granted. For instance, you could grant SELECT on
ks1.cf1 to user foo, but add a restriction such that multipartition queries are
not allowed. My first question then is are there other restrictions that would
be useful but which don't fit this definition?
For restrictions which do fit that definition, it seems sensible to use a
similar resource hierarchy as permissions. i.e. a restriction can be applied at
the table level, keyspace level (which trickles down to apply to all tables in
the ks), or at the root level. The alternative implied by the syntax in the
previous comments suggests that a restriction should always be applied at the
root level (i.e. for all keyspaces & tables).
How inheritance is handled in that hierarchy of resources should be from the
bottom upwards, working from the most specific permission/restriction.For
instance, in the case where user x is granted SELECT without any restriction on
ks1 and the same user is also granted SELECT with the MULTI_PARTITION
restriction on ks1.cf1 it seems clear that MP queries from user x should only
be disallowed on the one table, not all tables in ks1. Also, the unrestricted
grant should not trump the more specific, restricted one and allow MP queries
on that table.
In the reverse scenario, where the restriction is at the keyspace level, but
there is also a non-restricted grant for the table, the behaviour should also
be reversed, user x can make MP queries on the 1 table, but on no others in the
keyspace.
As noted, managing all this at the user level could be overly burdensome but
CASSANDRA-7653 should relieve most of that extra administrative load. However,
it would involve some additional complexity in handling resolution of
permissions and restrictions.
During the authz process when we resolve permissions for a user on a particular
resource, the most specific permission whether granted directly or inherited
through role membership should apply, along with any of its restrictions. If
there are multiple inherited or direct grants for the exact same resource (i.e.
at the same level in the resource hierarchy) then we would merge them, unioning
any restrictions, e.g
{noformat}
role x is granted SELECT on ks1 with MULTI_PARTITION restriction
role y is granted SELECT on ks1.cf1, unrestricted
role y should be allowed to SELECT from any table in ks1, but perform MP
queries on ks1.cf1 only
role z is granted both role x and role y
role z should be allowed to SELECT from any table in ks1, but perform MP
queries on ks1.cf1 only
role a is granted SELECT on ks1, unrestricted
role z is granted roles x, y, a
role z should be allowed to SELECT from any table in ks1, but perform MP
queries on ks1.cf1 only
{noformat}
So, I think this could fit nicely into authz for 3.0 but we may also want to
think about adding options to cassandra.yaml to enforce the same restrictions
without requiring authz (& authn). Obviously, that would be much more of a
blunt instrument - enforcing a given restriction for all queries when enabled,
though it would mean that it could be turned on on a per-node/per-DC basis. I
don't see a problem with supporting both cql and yaml based approaches so long
as we define an order of precedence.
> Provide "strict mode" for CQL Queries
> -------------------------------------
>
> Key: CASSANDRA-8303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8303
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Anupam Arora
> Fix For: 3.0
>
>
> Please provide a "strict mode" option in cassandra that will kick out any CQL
> queries that are expensive, e.g. any query with ALLOWS FILTERING,
> multi-partition queries, secondary index queries, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
