[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932925#comment-15932925
]
Boris Melamed commented on CASSANDRA-12859:
-------------------------------------------
Hi [[email protected]],
I have suspended my work on this ticket while still awaiting feedback /
resolution on multiple questions.
h4. Background summary
There was a very helpful initial discussion with [~beobal], based on which I
made the implementation so far.
In an attempt to do even better, I made GRANTing columns additive (not
'replacing'), and [~jjordan] has correctly pointed out that:
bq. 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.
Seems I'll have to either backtrack and make GRANT behavior replacing, or else
implement subtractive-ness for REVOKE, after all, even in v1 of this.
Jordan also suggested that columns should be a 3rd level in permission
hierarchies. However, the initially discussed, specced, and implemented
approach considers column permissions as restrictions on table permissions.
This follows what I perceive as the column permission paradigm of RDBMSs such
as MySQL, DB2, Oracle.
I have just pushed the fixes I mentioned in my previous post to my fork:
https://github.com/bmel/cassandra/tree/col-perms-12859.
h4. Summary of blocking issues
Before resuming my work, I would like the following questions resolved:
# Agreement on the originally approved approach of column permissions as
light-weight restrictions on table permissions, as opposed to an additional,
3rd resource level.
# Is there a spec for what's the expected behavior with permissions and MVs?
There are not many dtests for those, and from reading the code, it seems quite
different from RDBMS view permissions.
For example, in C*:
#* No permissions are required on an MV for SELECT. Only its base table must be
granted.
#* For modifying a base table, the user must have permissions on all its MVs.
This is starkly different from RDBMS, IMHO. I can try and proceed likewise for
columns, but would like to make sure this is expected.
# The "Remaining questions" (last section) in the uploaded doc Cassandra
Proposal - Column-level permissions v2.docx
# And lastly... It may make sense for someone to also review the code so far,
now that the basic feature is 'code-complete' and tested, in:
#* https://github.com/bmel/cassandra/tree/col-perms-12859.
#* https://github.com/bmel/cassandra-dtest (the last test line fails
rightfully; it reproduces the current leaking of permissions into re-created
columns)
Note though that I have not merged from trunk/master since last November.
> 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.docx,
> Cassandra Proposal - Column-level permissions v2.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.15#6346)
