[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15940240#comment-15940240
]
Stefan Podkowinski commented on CASSANDRA-12859:
------------------------------------------------
I'd like to share some feedback at this point, although I'm a bit late to the
discussion.
*GRANT - additive or replacing?*
Looks to me that preferring additive properties, for granting column
permissions, is already consensus here? I'd agree to that, but I'm not so happy
with the current "all columns" grant semantics.
bq. Granting a table permission without specifying columns allows access to all
the columns (unrestricted). Granting a table permission with a column list
restricts access to those columns only (restricted to a white list of columns).
This will put us in an odd situation when combining roles for both cases:
{noformat}
grant select to role1
grant select(a,b) to role2
grant role1, role2 to role3
{noformat}
Now we'd end up with more restrictive access for role3 than one if its
contained roles (role1).
Or another example:
{noformat}
grant select on keyspace ks1 on role1;
grant select(a,b) on keyspace ks1 table tb1 on role1;
{noformat}
Am I correct that the 2nd grant would restrict access to the listed columns and
override the less restricted access from the statement before? Isn't this
effectively blacklisting permissions?
*IAuthorizer*
Most parts of Cassandra are not build with extensibility in mind. But the
AuthN/Z handling can be configured to use custom implementations of the
IAuthenticator/IAuthorizer interfaces. There are third party implementations
out there that depend on this and I'd prefer not to break them without at least
first deprecating the old APIs.
*Remaining questions*
Maybe I can at least try to answer two of those..
bq. 1. Do we need to be concerned with thrift-created 'Raw' ColumnDefinitions?
CASSANDRA-8178
Thrift support will be gone in 4.0 (CASSANDRA-11115). Thrift specific table
definitions should be migrated during the 3.0 upgrade, if I'm not wrong. So I'd
assume this should not be a concern, but not 100% sure on that.
bq. 2. Do we need to be concerned about legacy non-role, user auth?
I don't think so. I've opened CASSANDRA-13371 for this.
> 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
> 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:
> * 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;}}
> # 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
> *
> 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)
