[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15625503#comment-15625503
]
Boris Melamed edited comment on CASSANDRA-12859 at 11/1/16 2:17 PM:
--------------------------------------------------------------------
Thank you, that would indeed fit nicely.
Here is a slightly modified example, to illustrate the difference between
required permissions. I'm mentioning PK columns in the required permissions,
just as other columns.
{code}
// Table schema definition:
CREATE ks.t1 (p int, c int, v int, w int, PRIMARY KEY (p,c));
// Accessing individual columns:
INSERT INTO ks.t1(p, c, v) VALUES (0, 0, 0); // requires MODIFY on at least
ks.t1(p, c, v)
SELECT v FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on at least
ks.t1(p, v)
UPDATE ks.t1 SET v = 1 WHERE p = 0 AND v = 0; // requires MODIFY on at least
ks.t1(p, v)
DELETE v FROM ks.t1 WHERE p = 0 AND v = 0; // requires MODIFY on at least
ks.t1(p, v)
// Accessing whole rows (all columns):
SELECT * FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on at least
ks.t1(p, c, v, w)
DELETE FROM ks.t1 WHERE p = 0 AND c = 0; // requires MODIFY on at least
ks.t1(p, c, v, w)
DELETE FROM ks.t1 WHERE p = 0; // requires MODIFY on at least
ks.t1(p, c, v, w)
TRUNCATE ks.t1; // requires MODIFY on at least
ks.t1(p, c, v, w)
{code}
was (Author: bmel):
Thank you, that would indeed fit nicely.
Here is a slightly modified example, to illustrate the difference between
required permissions. Note that in RDBMSs, even PK columns need to be given
access explicitly even for upsert. Following this approach could help avoid
confusion.
{code}
// Table schema definition:
CREATE ks.t1 (p int, c int, v int, w int, PRIMARY KEY (p,c));
// Accessing individual columns:
INSERT INTO ks.t1(p, c, v) VALUES (0, 0, 0); // requires MODIFY on at least
ks.t1(p, c, v)
SELECT v FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on at least
ks.t1(p, v)
UPDATE ks.t1 SET v = 1 WHERE p = 0 AND v = 0; // requires MODIFY on at least
ks.t1(p, v)
DELETE v FROM ks.t1 WHERE p = 0 AND v = 0; // requires MODIFY on at least
ks.t1(p, v)
// Accessing whole rows (all columns):
SELECT * FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on at least
ks.t1(p, c, v, w)
DELETE FROM ks.t1 WHERE p = 0 AND c = 0; // requires MODIFY on at least
ks.t1(p, c, v, w)
DELETE FROM ks.t1 WHERE p = 0; // requires MODIFY on at least
ks.t1(p, c, v, w)
TRUNCATE ks.t1; // requires MODIFY on at least
ks.t1(p, c, v, w)
{code}
> 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)
