cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Strickland (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-12859) Column-level permissions
Date Fri, 28 Oct 2016 17:26:58 GMT


Robbie Strickland updated CASSANDRA-12859:
    Attachment: Cassandra Proposal - Column-level permissions.docx

> Column-level permissions
> ------------------------
>                 Key: CASSANDRA-12859
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core, CQL
>            Reporter: Boris Melamed
>         Attachments: Cassandra Proposal - Column-level permissions.docx
>   Original Estimate: 504h
>  Remaining Estimate: 504h
> Here is a draft of: 
> Cassandra Proposal - Column-level permissions.docx
> Quoting the 'Overview' section:
> The purpose of this proposal is to add column-level (field-level) permissions to Cassandra.
It is my intent to soon start implementing this feature in a fork, and to submit a pull request
once it’s ready.
> Motivation
> Cassandra already supports permissions on keyspace and table (column family) level. Sources:
> -
> -
> At IBM, we have use cases in the area of big data analytics where column-level access
permissions are also a requirement. All industry RDBMS products are supporting this level
of permission control, and regulators are expecting it from all data-based systems.
> Main day-one requirements
> 1.	Extend CQL (Cassandra Query Language) to be able to optionally specify a list of individual
columns, in the GRANT statement. The relevant permission types are: MODIFY (for UPDATE and
> 2.	Persist the optional information in the appropriate system table ‘system_auth.role_permissions’.
> 3.	Enforce the column access restrictions during execution. Details:
>   a.	Should fit with the existing permission propagation down a role chain.
>   b.	Proposed message format when a user’s roles give access to the queried table but
not to all of the selected, inserted, or updated columns:
>   "User %s has no %s permission on column %s of table %s"
>   c.	Error will report only the first checked column. 
> Nice to have: list all inaccessible columns.
>   d.	Error code is the same as for table access denial: 2100.
> Additional day-one requirements
> 4.	Reflect the column-level permissions in statements of type 
> 5.	Performance should not degrade in any significant way.
> 6.	Backwards compatibility
>   a.	Permission enforcement for DBs created before the upgrade should continue to work
with the same behavior after upgrading to a version that allows column-level permissions.
>   b.	Previous CQL syntax will remain valid, and have the same effect as before.
> 7.	Documentation
>   o
>   o	Feedback request: any others?

This message was sent by Atlassian JIRA

View raw message