[
https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915965#action_12915965
]
Eric Evans commented on CASSANDRA-1271:
---------------------------------------
Ok, this has been committed with one simple but significant change, namely that
the READ_VALUE/WRITE_VALUE perms have been removed.
This has no effect at all on the only implemented authority, SimpleAuthority,
but it does mean that it's not possible to implement an authority that
distinguishes between writing a column family versus writing the data contained
within. For this, it would be better to take advantage of the resource
hierarchy and authorize differently depending on the operation. I will submit
a separate ticket to implement that.
Thanks Stu, between this and the related issues this all looks significantly
better than what we had before.
> Improve permissions to allow control over creation/removal/listing of
> Keyspaces
> -------------------------------------------------------------------------------
>
> Key: CASSANDRA-1271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1271
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Stu Hood
> Assignee: Eric Evans
> Priority: Minor
> Fix For: 0.7.0
>
> Attachments: 1271-v3.tgz
>
>
> We'd like to improve resources/permissions so that they can be applied to the
> global scope, instead of just individual keyspaces.
> IAuthority currently only has one concept of a resource that it can authorize
> for: a keyspace. At the very least, this ticket needs to deal with one
> additional resource: "the keyspace list". These resources should be mapped
> into a hierarchy, and an object representing the path to the resource will be
> passed to IAuthority.
> A resource hierarchy to represent all possible resources in Cassandra might
> look like: {{/cassandra/<cluster_name>/keyspaces/<ks_name>/...}}
> In table form:
> || resource || checked perms || explanation ||
> | /cassandra/ | n/a | Separates Cassandra-internal resources from resources
> that might be provided by plugins. |
> | <cluster_name>/ | n/a | Organizations might have many clusters |
> | keyspaces/ | READ, WRITE | The list of keyspaces: READ/WRITE for this
> resource mean the ability to view/modify the list of keyspaces. |
> | <ks_name>/ | READ, WRITE, READ_VALUE, WRITE_VALUE | An individual keyspace:
> READ/WRITE mean the ability to view/modify the list of column families. Since
> this is the last entry in the current hierarchy, READ/WRITE_VALUE apply
> recursively to ancestor _data_ of this keyspace. |
> Over time Cassandra _may_ add additional authorize calls for resources higher
> or lower in the chain, which IAuthority backends can choose to ignore, but
> this initial patch will only make authorize calls for the keyspaces list, and
> individual keyspaces. As authorize calls are added for child resources like
> {{<cf_name>/}}, the READ/WRITE_VALUE permissions will move to the lowest
> checked level, and will be deprecated at higher levels.
> (Note that {{/cassandra/}} and {{<cluster_name>/}} will not yet be checked
> for permissions via a call to IAuthority.authorize, so while it would be
> possible for an IAuthority backend to store permissions for these top level
> resources, they will only be able to deny access when a user attempts to
> access an ancestor resource.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
