[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271: -------------------------------- Attachment: 0002-Convert-to-List-Object-resources.patch Forgot to remove a mention of <cluster_name>: decided not to use it in the resource hierarchy, since it doesn't change at runtime, and is accessible elsewhere. > 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.