Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 20 Mar 2017 16:08:42 +0000 (UTC)
From: "Boris Melamed (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13016179.1477666568000.66821.1490026122009@Atlassian.JIRA>
In-Reply-To: <JIRA.13016179.1477666568000@Atlassian.JIRA>
References: <JIRA.13016179.1477666568000@Atlassian.JIRA> <JIRA.13016179.1477666568550@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CASSANDRA-12859) Column-level permissions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Mon, 20 Mar 2017 16:08:50 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-12859?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15932925#comment-15932925 ]=20

Boris Melamed commented on CASSANDRA-12859:
-------------------------------------------

Hi [~spodxx@gmail.com],
I have suspended my work on this ticket while still awaiting feedback / res=
olution 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 'rep=
lacing'), and [~jjordan] has correctly pointed out that:

bq. I think it should be required for grant and revoke to work in a complem=
entary fashion in v1 of this. So either grant replaces and revoke removes a=
ll. Or grant is additive and revoke is subtractive. If this is not how it w=
orks then it is impossible to remove access to a column without having an o=
utage for an application that has stopped using said column.

Seems I'll have to either backtrack and make GRANT behavior replacing, or e=
lse implement subtractive-ness for REVOKE, after all, even in v1 of this.
Jordan also suggested that columns should be a 3rd level in permission hier=
archies. However, the initially discussed, specced, and implemented approac=
h considers column permissions as restrictions on table permissions. This f=
ollows 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: ht=
tps://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 li=
ght-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 qu=
ite different from RDBMS view permissions.
For example, in C*:
#* No permissions are required on an MV for SELECT. Only its base table mus=
t be granted.
#* For modifying a base table, the user must have permissions on all its MV=
s. This is starkly different from RDBMS, IMHO. I can try and proceed likewi=
se for columns, but would like to make sure this is expected.

# The "Remaining questions" (last section) in the uploaded doc Cassandra Pr=
oposal - Column-level permissions v2.docx

# And lastly... It may make sense for someone to also review the code so fa=
r, now that the basic feature is 'code-complete' and tested, in:
#* https://github.com/bmel/cassandra/tree/col-perms-12859.=20
#* https://github.com/bmel/cassandra-dtest (the last test line fails rightf=
ully; it reproduces the current leaking of permissions into re-created colu=
mns)

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-1285=
9
>             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:=20
> Cassandra Proposal - Column-level permissions.docx (attached)
> h4. Quoting the 'Overview' section:
> The purpose of this proposal is to add column-level (field-level) permiss=
ions to Cassandra. It is my intent to soon start implementing this feature =
in a fork, and to submit a pull request once it=E2=80=99s ready.
> h4. Motivation
> Cassandra already supports permissions on keyspace and table (column fami=
ly) 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 product=
s are supporting this level of permission control, and regulators are expec=
ting 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 perm=
ission types are: {{MODIFY}} (for {{UPDATE}} and {{INSERT}}) and {{SELECT}}=
.
> # Persist the optional information in the appropriate system table =E2=80=
=98system_auth.role_permissions=E2=80=99.
> # 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=E2=80=99s 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.=20
> 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=20
> {{LIST ALL PERMISSIONS OF someuser;}}
> # When columns are dropped or renamed, trigger purging or adapting of the=
ir permissions
> # Performance should not degrade in any significant way.
> # Backwards compatibility
> #* Permission enforcement for DBs created before the upgrade should conti=
nue 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 bef=
ore.
> 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)