cassandra-commits mailing list archives

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

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

Boris Melamed edited comment on CASSANDRA-12859 at 12/7/16 1:37 PM:
--------------------------------------------------------------------

Arguably, this is the ultimate goal.
Yet actually, the REVOKE direction is as user-unfriendly as initially planned, after the above
discussions, for both GRANT and REVOKE. But at least GRANT is now more user-friendly than
that. 

In therms of coding, it's not a big effort to make REVOKE subtractive.
For now, would you agree to add the current functionality (pending review) to the trunk, or
do you consider this an 'all or nothing' situation?

Moreover, making REVOKE subtractive opens a can of worms.
As background, please see section "Some details on permission lifecycle and precedence" in
the attached 'v2' document.
Consider these potentially confusing cases, especially #2:

1. Last column gets subtracted
* GRANT SELECT(c1, c2) ON ks.t1 TO Joe; -- Joe can select c1 and c2 from t1
* REVOKE SELECT(c2) ON ks.t1 FROM Joe; -- Joe can select only c1 from t1
* REVOKE SELECT(c1) ON ks.t1 FROM Joe; -- What now?

After the last command, should Joe have access to all of t1, or should his access to t1 get
revoked altogether? I'm guessing the latter, but would like this confirmed.

2. Subtracting a column that had not been added
* GRANT SELECT ON ks.t1 TO Joe; -- Joe can select all of t1
* REVOKE SELECT(c2) ON ks.t1 FROM Joe; -- What now?

After the REVOKE, should Joe have access to all of t1's columns except for c2? This might
be a natural expectation. However, we're not planning on introducing black lists. We could
'fake it' by restricting the permission to all columns except for c2, equivalent to (informally):

* GRANT SELECT(c1,c3,c4,...) ON ks.t1 TO Joe; -- Joe can select all of t1 except for c2

But then, Joe would not be able to access columns that got added afterwards.
So I would suggest that revoking columns that are not in the current permission constraint
should have no effect on permissions. But this may not follow a user's intuition, and needs
to be clearly documented.

In any case, I'm guessing that these other tasks should be the next in line, before this feature
can get into the product:

* LIST PERMISSIONS
* Purging of column constraints after dropping columns



was (Author: bmel):
Arguably, this is the ultimate goal.
Yet actually, the REVOKE direction is as user-unfriendly as initially planned, after the above
discussions, for both GRANT and REVOKE. But at least GRANT is now more user-friendly than
that. 

In therms of coding, it's not a big effort to make REVOKE subtractive.
For now, would you agree to add the current functionality (pending review) to the trunk, or
do you consider this an 'all or nothing' situation?

Moreover, making REVOKE subtractive opens a can of worms.
As background, please see section "Some details on permission lifecycle and precedence" in
the attached 'v2' document.
Consider these potentially confusing cases, especially #2:

1. Last column gets subtracted
** GRANT SELECT(c1, c2) ON ks.t1 TO Joe; -- Joe can select c1 and c2 from t1
** REVOKE SELECT(c2) ON ks.t1 FROM Joe; -- Joe can select only c1 from t1
** REVOKE SELECT(c1) ON ks.t1 FROM Joe; -- What now?

After the last command, should Joe have access to all of t1, or should his access to t1 get
revoked altogether? I'm guessing the latter, but would like this confirmed.

2. Subtracting a column that had not been added
** GRANT SELECT ON ks.t1 TO Joe; -- Joe can select all of t1
** REVOKE SELECT(c2) ON ks.t1 FROM Joe; -- What now?

After the REVOKE, should Joe have access to all of t1's columns except for c2? This might
be a natural expectation. However, we're not planning on introducing black lists. We could
'fake it' by restricting the permission to all columns except for c2, equivalent to (informally):

** GRANT SELECT(c1,c3,c4,...) ON ks.t1 TO Joe; -- Joe can select all of t1 except for c2

But then, Joe would not be able to access columns that got added afterwards.
So I would suggest that revoking columns that are not in the current permission constraint
should have no effect on permissions. But this may not follow a user's intuition, and needs
to be clearly documented.

In any case, I'm guessing that these other tasks should be the next in line, before this feature
can get into the product:

* LIST PERMISSIONS
* Purging of column constraints after dropping columns


> 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