[
https://issues.apache.org/jira/browse/CASSANDRA-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538244#comment-14538244
]
Jonathan Shook commented on CASSANDRA-8303:
-------------------------------------------
I am concerned that we are creating more complexity through pedantry here. Let
me explain...
I know this is late in coming, but I'm going to explain my position anyway.
The idea that a user would be authorized for an operation does not depend on it
being on specific data. There is no hard and fast rule that says you must not
use authorization to control access to types of actions. From the general
perspective, that is what authorization is about. It is simply a mechanism to
answer the question "Is the current user allowed to do ____?" This is not
strictly limited to accessing specific data, but may also be used to limit
access to specific types of actions which are not data-specific. To assert that
it is is to ignore lots of established practice across a great number of
systems. Authorization is a general concept which needs to be applied in a
conceptually useful and idiomatic way for each system.
There is a variety of approaches in the wild for how to structure permissions.
Some of them assume no access with exclusions in the form of grants. Some do
the opposite. My favorite is the 3-state logic used by the postfix MTA (thank
you, Venema!) which allows for a very plugable system. In this system, a chain
of evaluators is used, and each may grant, deny, or indicate "I don't know, ask
the next one".. And all you have to do to establish a default is put a static
grant or deny at the end of the evaluator chain. So, this is a bit
non-sequitor, but the point is to illustrate the variety and flexibility of
"authorization" systems out there. A competing concern for the flexibility of
these system is always how easy they are to understand and use. That feeds
directly into my next point.
I don't understand why we would want to create two semantically distinct
interfaces for users when we are really talking about a basic authentication
problem. Group or individual, data-oriented or command-oriented. Once you've
made the user pay the price of entry to use the authentication system, you're
going to tell them that they have to learn a different system to do "capability
limiting" because we decided to name it and treat it differently? I think this
is a case of accidental complexity in the name of separation of concerns, when
in fact they are not really separate concerns.
You can't completely separate the mechanisms of authorization, group
membership, and capabilities. They may have cleanly defined APIs, but if you
look at the implementation details of CASSANDRA-7653, saying that they are
logically separate would be a half-truth at best. Indeed, the authentication
data has been pulled up to be visible and owned by the group management logic.
You simply can't have group authentication without authentication. How they are
mapped together is another matter. I would assert that authenticating
individuals and mapping them via groups would probably be cleaner, but the
mechanisms would still need to be inextricably linked at some layer.
>From a security perspective, limiting commands is every bit a part of managing
>system availability in a security and continuation sense as other forms of
>authentication+authorization. Think about DOS attacks and what it means to
>prevent them via command restrictions. It's just that some of the commands are
>data-specific, and some are not. You simply can not have a proper and separate
>subsystem for limiting commands without mostly reinventing the wheel around
>authentication and authorization.
So, regardless of how it's implemented, I don't think we should be trying to
designate "authorization" and "limiting allowed commands" as different concerns
from the user's perspective. If you subscribe to that mindset, any notion that
they would be implemented as rigidly isolated subsystems would be a reason for
concern. I'm all for keeping the implemention clean and composable. I just
don't want to see us shoot ourselves in the foot because we are forcing
separation when there is conceptual, logical, and mechanical affinity.
I uncomfortable with the suggestion under "What does this buy us?, #5" that
this would simply be vetoed if it weren't done the way suggested above. Was
that meant to be a qualification of how this ticket can move forward?
> Create a capability limitation framework
> ----------------------------------------
>
> Key: CASSANDRA-8303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8303
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Anupam Arora
> Assignee: Sam Tunnicliffe
> Fix For: 3.x
>
>
> In addition to our current Auth framework that acts as a white list, and
> regulates access to data, functions, and roles, it would be beneficial to
> have a different, capability limitation framework, that would be orthogonal
> to Auth, and would act as a blacklist.
> Example uses:
> - take away the ability to TRUNCATE from all users but the admin (TRUNCATE
> itself would still require MODIFY permission)
> - take away the ability to use ALLOW FILTERING from all users but
> Spark/Hadoop (SELECT would still require SELECT permission)
> - take away the ability to use UNLOGGED BATCH from everyone (the operation
> itself would still require MODIFY permission)
> - take away the ability to use certain consistency levels (make certain
> tables LWT-only for all users, for example)
> Original description:
> 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)
