cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-8303) Create a capability limitation framework
Date Mon, 08 Aug 2016 09:25:20 GMT


Sam Tunnicliffe updated CASSANDRA-8303:
    Status: Patch Available  (was: In Progress)

I've pushed a branch with the bones of an implementation, there are a few things left to do
on it but nothing that needs to hold up review really. I've also added a new dtest fixture.

As [~zznate] suggested, I've left out the generational cache stuff for now. My preference
is still to include this in the final patch, rather than defer it to a separate ticket which
I think should be feasible. It ought to be as straightforward as dropping in a caching {{RestrictionHandler}}
which delegates to the table-based one to populate the cache. Obviously, there's slightly
more to consider, but I'm hopeful of getting it in before commit but if that's not possible,
at least it isn't blocking anything.

Other stuff which is outstanding & on my todo list:
* javadoc, in-tree docs and commenting new properties in cassandra.yaml
* metrics
* cqlsh help & completion
* there are a couple of unit tests which are just placeholders & need implementing
* performance test

||branch||dtest branch||testall||dtest||

> Create a capability limitation framework
> ----------------------------------------
>                 Key: CASSANDRA-8303
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Distributed Metadata
>            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

View raw message