cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boris Melamed (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12859) Column-level permissions
Date Mon, 20 Mar 2017 16:08:42 GMT


Boris Melamed commented on CASSANDRA-12859:

Hi [],
I have suspended my work on this ticket while still awaiting feedback / resolution on multiple

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:

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:
#* (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:
>             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:
> *
> *
> 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 
> # 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
> *
> * Feedback request: any others?

This message was sent by Atlassian JIRA

View raw message