[
https://issues.apache.org/jira/browse/CASSANDRA-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14273851#comment-14273851
]
Aleksey Yeschenko commented on CASSANDRA-8303:
----------------------------------------------
After some IRC discussion we came up with another suggestion. As before, ignore
the naming and the syntax, these are purely illustrative.
The proposed new restrictions, while useful, do not conceptually fit with the
concept of authorization. Authorization is about what data a particular role
can access and/of modify, not about the particular query details. As far as
authorization is concerned, there should be no distinction between writing a
single partition to table 'foo' or two, in a batch - all that matters is that
data in table 'foo' is being modified. I will strongly insist on it staying
this way.
There is also broad agreement that we need a way to broadly limit users'
ability to harm cluster's performance with indexes, filtering, and batches
(among other things).
Given that we have roles now (or, rather, will have very soon - likely to be
committed today or tomorrow) it seems natural to reuse the concept of roles for
this broad capability management.
It doesn't mean, however, that we should use authorization for this (which I'm
strongly -1 on). The way Sam and Mike designed CASSANDRA-7653, roles,
authentication, and authorization - are three separate concepts, and three
separate APIs (IRoleManager, IAuthenticator, IAuthorizer). So we can take roles
and authentication, leave out authorization, and add an extra API (say,
ICapabilityManager) that would manage roles' restrictions on operation types a
role can perform, not tied to any particular keyspace or table.
On CQL side, we'd have something like this (syntax intentionally silly to
prevent bikeshedding at this early stage):
TAKE AWAY FILTERING FROM 'foo';
GIVE BACK BATCHES TO 'bar';
TAKE AWAY TRUNCATE FROM 'baz'; (I believe TRUNCATE belongs here, not to
permissions - there we already have MODIFY)
Shouldn't reuse GRANT/REVOKE because authorization/permission are conceptually
a whitelist. A role has none unless it's granted some. Capability restrictions
work as a black list - you can do any of those operations until someone puts a
restriction on you.
Permissions and restrictions are also inherited differently from parent roles.
What does this buy us?
1. Being a new API, there is no rush for implementing it by 3.0.0 - we are now
in aggressive feature scope cut mode.
2. If you don't care about authorization (which can be expensive, too), you can
still enable broad restrictions, since they wouldn't rely on IAuthorizer
3. If you don't care about capability restrictions, but only about
authorization, you can only enable IAuthorizer. The two APIs are nicely
orthogonal.
4. IAuthorizer stays simple - both conceptually and implementation-wise. You
don't want your security code be complex, for obvious reasons, but you also
don't want the model to be confusing, which it would be if you tried to mix
restrictions on batches and filtering with stuff like MODIFY and SELECT.
5. It can actually happen without being vetoed.
> 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)
