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 Mon, 31 Oct 2016 16:13:59 GMT

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

Boris Melamed edited comment on CASSANDRA-12859 at 10/31/16 4:13 PM:
---------------------------------------------------------------------

Thank you for giving this doc your attention, and for your feedback.
I was taking cues from what the big RDBMS products have to offer, mainly DB2 and Oracle.

Now to your points:

h4. MODIFY as also including DELETE and TRUNCATE.
I remember seeing a previous request to divide it up. The reason given not to divide was that
once you have UPDATE rights, you can also effectively remove whole rows (DELETE, TRUNCATE).
However, with column permissions, this is no longer the case. I agree that it's scary (or
outright wrong) to allow someone with a mere column permission to remove whole rows. On the
other hand, if DELETE requires a MODIFY permission without any column restrictions, then there
is no way (even if needed) of allowing anyone to delete rows unless they have UPDATE permissions
for the whole table. Possibly, that's a valid stipulation - TBD.

{quote}
Why not just process deletes/truncates the same as inserts?
{quote}
For inserts, I intended to reject statements that set columns for which the user has no access
permissions. Are you saying that INSERTs should not be restricted by columns?
(Note that primary key columns must be allowed, or else no INSERT/UPDATE is possible. I shall
add this to the doc...)

Should we add a new permission type, such as UPDATE or UPSERT, after all?
----
h4. GRANT - additive or replacing?
In Oracle and DB2, it's actually required to REVOKE table permissions, 
before changing the list of included columns in any way.
I've intended allowing 'replacing' GRANTs as syntactic sugar.
But now, it seems to me that the "spartan" way is the most unambiguous one. 
If one wants to add or remove one or more columns from the list of included columns, then
 e.g.:

{code}
GRANT SELECT (col_a, col_b) ON ks.t1 TO foo; // role foo has access to col_a and col_b
REVOKE SELECT ON ks.t1 FROM foo; // removing the previous access to table t1, thus clearing
column perms there as well
GRANT SELECT (col_a, col_b, col_c) ON ks.t1 TO foo; // now, foo has permissions on all of
col_a, col_b, col_c
{code}

Having said this, there are several DB products that do allow revoking of permissions on certain
columns. There, it would make sense to have the additive column GRANTing paradigm, as your
intuition suggests.
However, possible problems with that approach, as user-friendly as it appears, are:
# More complexity: grammar addition for REVOKE statements as well.
# Possible confusion: users may erroneously think that the following allows access to all
columns (including future ones) except col_a:

{code}
GRANT SELECT ON ks.t1 TO foo;
REVOKE SELECT (col_a) ON ks.t1 FROM foo;
{code}

Of course, this will not work unless we implement black lists, which we have not thought of
doing.

As a remedy, we could return an error when REVOKE refers to a column that does not exist.
If there are strong feelings for having this more elaborate paradigm, then we can do that.
Otherwise, at least in the first step, I'd go for the 'spartan' approach where any column
list change requires a previous REVOKE on the whole table, for that role, table, and permission
type. The nice thing being that there will be no issue with backwards compatibility going
forward, since we are not deciding whether GRANTed columns are additive or replacing; it's
simply forbidden to GRANT again, without first REVOKEing.
----

h4. Misc
* Thank you for unit test pointers.
* Absolutely, dropped columns must trigger cleanup of permissions, thanks for pointing this
out.
* Grammar- indeed. It would be simpler to have the non-standard syntax:
{code}
GRANT SELECT ON ks.t1 (col_a, ...) TO foo;
{code}
If there are no objections, I may go for that. Or else, the code could check and throw an
exception if the resource is not a table.
* I shall look deeper into the code and come back about the IResource aspect.



was (Author: bmel):
Thank you for giving this doc your attention, and for your feedback.
I was taking cues from what the big RDBMS products have to offer, mainly DB2 and Oracle.

Now to your points:

h4. MODIFY as also including DELETE and TRUNCATE.
I remember seeing a previous request to divide it up. The reason given not to divide was that
once you have UPDATE rights, you can also effectively remove whole rows (DELETE, TRUNCATE).
However, with column permissions, this is no longer the case. I understand that it's scary
(or outright wrong) to allow someone with a mere column permission to remove whole rows. On
the other hands, if DELETE requires MODIFY permission without column restrictions, then there
is no way (even if needed) of allowing anyone to delete rows unless they have UPDATE every
column. Possibly, that's a valid stipulation - TBD.

{quote}
Why not just process deletes/truncates the same as inserts?
{quote}
For inserts, I intended to reject statements that set columns for which the user has no access
permissions. Are you saying that INSERTs should not be restricted by columns?
(Note that primary key columns must be allowed, or else no INSERT/UPDATE is possible. I shall
add this to the doc...)

Should we add a new permission type, such as UPDATE or UPSERT, after all?
----
h4. GRANT - additive or replacing?
In Oracle and DB2, it's actually required to REVOKE table permissions, 
before changing the list of included columns in any way.
I've intended allowing 'replacing' GRANTs as syntactic sugar.
But now, it seems to me that the "spartan" way is the most unambiguous one. 
If one wants to add or remove one or more columns from the list of included columns, then
 e.g.:

{code}
GRANT SELECT (col_a, col_b) ON ks.t1 TO foo; // role foo has access to col_a and col_b
REVOKE SELECT ON ks.t1 FROM foo; // removing the previous access to table t1, thus clearing
column perms there as well
GRANT SELECT (col_a, col_b, col_c) ON ks.t1 TO foo; // now, foo has permissions on all of
col_a, col_b, col_c
{code}

Having said this, there are several DB products that do allow revoking of permissions on certain
columns. 
There, it would make sense to have the additive column GRANTing paradigm, as your intuition
suggests.
However, possible problems with that approach, as user-friendly as it appears, are:
# More complexity: grammar addition for REVOKE statements as well.
# Possible confusion: users may erroneously think that the following allows access to all
columns (including future ones) except col_a:

{code}
GRANT SELECT ON ks.t1 TO foo;
REVOKE SELECT (col_a) ON ks.t1 FROM foo;
{code}

Of course, this will not work unless we implement black lists, which we have not thought of
doing.

As a remedy, we could return an error when REVOKE refers to a column that does not exist.
If there are strong feelings for having this more elaborate paradigm, then we can do that.
Otherwise, at least in the first step, I'd go for the 'spartan' approach where any 
column list change requires a previous REVOKE on the whole table, for that role, table, and
permission type. The nice thing being that there will be no issue with 
backwards compatibility going forward, since we are not deciding whether GRANTed columns are
additive or replacing; it's simply
forbidden to GRANT again, without first REVOKEing.
----

h4. Misc
* Thank you for unit test pointers.
* Absolutely, dropped columns must trigger cleanup of permissions, thanks for pointing this
out.
* Grammar- indeed. It would be simpler to have the non-standard syntax:
{code}
GRANT SELECT ON ks.t1 (col_a, ...) TO foo;
{code}
If there are no objections, I may go for that. Or else, the code could check and throw an
exception if the resource is not a table.
* I shall look deeper into the code and come back about the IResource aspect.


> 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
>         Attachments: 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;}}
> # 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