Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 31 Oct 2016 16:08:58 +0000 (UTC)
From: "Boris Melamed (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13016179.1477666568000.133851.1477930138751@Atlassian.JIRA>
In-Reply-To: <JIRA.13016179.1477666568000@Atlassian.JIRA>
References: <JIRA.13016179.1477666568000@Atlassian.JIRA> <JIRA.13016179.1477666568550@arcas>
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, 31 Oct 2016 16:09:02 -0000


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

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

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 DB=
2 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 re=
move 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 ot=
her hands, if DELETE requires MODIFY permission without column restrictions=
, then there is no way (even if needed) of allowing anyone to delete rows u=
nless 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,=20
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.=
=20
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 t=
1, thus clearing column perms there as well
GRANT SELECT (col_a, col_b, col_c) ON ks.t1 TO foo; // now, foo has permiss=
ions on all of col_a, col_b, col_c
{code}

Having said this, there are several DB products that do allow revoking of p=
ermissions on certain columns.=20
There, it would make sense to have the additive column GRANTing paradigm, a=
s your intuition suggests.
However, possible problems with that approach, as user-friendly as it appea=
rs, 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 hav=
e not thought of doing.

As a remedy, we could return an error when REVOKE refers to a column that d=
oes 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 wh=
ere any=20
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 n=
o issue with=20
backwards compatibility going forward, since we are not deciding whether GR=
ANTed 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 f=
or 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 chec=
k and throw an exception if the resource is not a table.
* I shall look deeper into the code and come back about the IResource aspec=
t.


> 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
>         Attachments: Cassandra Proposal - Column-level permissions.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;}}
> # 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.4#6332)