[ https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622658#comment-15622658 ]
Sam Tunnicliffe commented on CASSANDRA-12859: --------------------------------------------- bq.MODIFY as also including DELETE and TRUNCATE Actually, I think I wasn't very clear what I meant. For inserts & updates, you'll be inspecting the set of modified columns and checking the permissions for those individually. For column-level deletes I think you could apply the same logic, e.g. (thinking only about regular columns at the moment, so leaving aside primary key columns) {code} CREATE ks.t1 (p int, c int, v int, PRIMARY KEY (p,c)); INSERT INTO ks.t1(p, c, v) VALUES (0, 0, 0); // requires MODIFY on ks.t1(v) UPDATE ks.t1 SET v = 1 WHERE p = 0 AND v = 0; // requires MODIFY on ks.t1(v) DELETE v FROM ks.t1 WHERE p = 0 AND v = 0; // requires MODIFY on ks.t1(v) {code} Of course, row/partition level deletes don't specify the columns, but this is generally the same as a SELECT \*, where you'll need to inspect the table metadata to check that the user has SELECT permissions on all columns which *may* be returned. So you could take that same approach to DELETE (& TRUNCATE). {code} SELECT v FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on ks.t1(v) SELECT * FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on ks.t1(v) DELETE FROM ks.t1 WHERE p = 0 AND c = 0; // requires MODIFY on ks.t1(v) DELETE FROM ks.t1 WHERE p = 0; // requires MODIFY on ks.t1(v) {code} This way you've limited the ability of the user to modify the date exactly in accordance with their granted permissions. > 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)