[ 
https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stu Hood updated CASSANDRA-1271:
--------------------------------

    Attachment:     (was: 0002-Convert-to-List-Object-resources.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
>            Assignee: Eric Evans
>            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
>
>
> 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.

Reply via email to