[
https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: 0003-Check-for-permissions-to-modify-the-keyspace-list.patch
> 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
> Priority: Minor
> Fix For: 0.7.0
>
> Attachments:
> 0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.patch,
> 0002-Convert-to-List-Object-resources.patch,
> 0003-Check-for-permissions-to-modify-the-keyspace-list.patch,
> 0004-Make-SimpleAuthority-aware-of-the-keyspace-list-reso.patch,
> 0005-Add-authorization-to-describe_keyspace-s-and-change-.patch
>
>
> 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.
