cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CASSANDRA-1271) Improve permissions to allow control over creation/removal/listing of Keyspaces
Date Sat, 28 Aug 2010 05:34:16 GMT

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

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

    Attachment: 0004-Make-SimpleAuthority-aware-of-the-keyspace-list-reso.patch
                0005-Add-authorization-to-describe_keyspace-s-and-change-.patch

0001 - Rather than making the contents of the ClientState object being ThreadLocals, the ClientState
object should be ThreadLocal (facepalm, but basically unrelated to the rest of this patchset)
0002 - Replace the 'keyspace' argument to authorize with a List<Object>. The intention
here is that we never have to create new objects to perform authorization, since we can keep
the resource list and replace the positions with whatever we have on hand (namely, Strings,
but also byte[]s, for when people ask for row-level auth).
0003 - Add permissions checks for modifications to the keyspace list
0004 - Implement keyspace list authorization in SimpleAuthority
0005 - Adds auth checks to describe_keyspace(s), and consequently needs to add InvalidRequestException.
(Rather than using InvalidRequestException, should we be throwing AuthorizationException everywhere?)

> 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.


Mime
View raw message