cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremiah Jordan (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-12859) Column-level permissions
Date Wed, 07 Dec 2016 15:06:58 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15728964#comment-15728964
] 

Jeremiah Jordan edited comment on CASSANDRA-12859 at 12/7/16 3:06 PM:
----------------------------------------------------------------------

This should work like tables and keyspaces work.

If I grant access to ks1 then revoke ks1.t1 what happens?  The same thing that happens for
that should happen for grant access to ks1.t1 then revoke access to ks1.t1.c1.

The same should be true for the other cases described as well.

I think it should be required for grant and revoke to work in a complementary fashion in v1
of this. So either grant replaces and revoke removes all. Or grant is additive and revoke
is subtractive.  If this is not how it works then it is impossible to remove access to a column
without having an outage for an application that has stopped using said column.

GRANT SELECT(c1,c2,c3) ON ks1.t1 TO r1;

Application usIng r1 never uses c3 so you decide to revoke access to that.

In order to not disrupt the application you need to be able to do that in one command. Either
GRANT SELECT(c1,c2) ON ks1.t1 TO r1;
To overwrite the old columns.  Or
REVOKE SELECT(c1) ON ks1.t1

Also given that this is basically adding a 3rd level to the hierarchy should we actually grant
a single column at a time and make it GRANT SELECT ON ks1.t1.c1 TO r1?  Then we don't have
to worry about the "()" stuff being valid, it is just adding a 3rd level to the data resource
hierarchy.


was (Author: jjordan):
This should work like tables and keyspaces work.

If I can't access to ks1 then revoke ks1.t1 what happens?  The same thing that happens for
that should happen for grant access to ks1.t1 then revoke access to ks1.t1.c1.

The same should be true for the other cases described as well.

I think it should be required for grant and revoke to work in a complementary fashion in v1
of this. So either grant replaces and revoke removes all. Or grant is additive and revoke
is subtractive.  If this is not how it works then it is impossible to remove access to a column
without having an outage for an application that has stopped using said column.

GRANT SELECT(c1,c2,c3) ON ks1.t1 TO r1;

Application usIng r1 never uses c3 so you decide to revoke access to that.

In order to not disrupt the application you need to be able to do that in one command. Either
GRANT SELECT(c1,c2) ON ks1.t1 TO r1;
To overwrite the old columns.  Or
REVOKE SELECT(c1) ON ks1.t1

Also given that this is basically adding a 3rd level to the hierarchy should we actually grant
a single column at a time and make it GRANT SELECT ON ks1.t1.c1 TO r1?  Then we don't have
to worry about the "()" stuff being valid, it is just adding a 3rd level to the data resource
hierarchy.

> Column-level permissions
> ------------------------
>
>                 Key: CASSANDRA-12859
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12859
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core, CQL
>            Reporter: Boris Melamed
>              Labels: doc-impacting
>         Attachments: Cassandra Proposal - Column-level permissions v2.docx, Cassandra
Proposal - Column-level permissions.docx
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> h4. Here is a draft of: 
> Cassandra Proposal - Column-level permissions.docx (attached)
> h4. 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.
> h4. Motivation
> Cassandra already supports permissions on keyspace and table (column family) level. Sources:
> * http://www.datastax.com/dev/blog/role-based-access-control-in-cassandra
> * https://cassandra.apache.org/doc/latest/cql/security.html#data-control
> 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.
> h4. Main day-one requirements
> # 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 {{INSERT}}) and {{SELECT}}.
> # Persist the optional information in the appropriate system table ‘system_auth.role_permissions’.
> # Enforce the column access restrictions during execution. Details:
> #* Should fit with the existing permission propagation down a role chain.
> #* 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"
> #* Error will report only the first checked column. 
> Nice to have: list all inaccessible columns.
> #* Error code is the same as for table access denial: 2100.
> h4. Additional day-one requirements
> # Reflect the column-level permissions in statements of type 
> {{LIST ALL PERMISSIONS OF someuser;}}
> # When columns are dropped or renamed, trigger purging or adapting of their permissions
> # Performance should not degrade in any significant way.
> # Backwards compatibility
> #* 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.
> #* Previous CQL syntax will remain valid, and have the same effect as before.
> h4. Documentation
> * https://cassandra.apache.org/doc/latest/cql/security.html#grammar-token-permission
> * Feedback request: any others?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message