You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stu Hood (JIRA)" <ji...@apache.org> on 2010/07/13 00:20:52 UTC
[jira] Created: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
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
Once 1237 is completed, we'd like to improve AccessLevels so that they can be applied to the global scope, instead of just individual keyspaces.
Steps for this ticket:
* Improve/replace the AccessLevel structure to be more like a set of boolean permissions, rather than being level based
* Store a global map of (users/groups)->AccessLevel that will define which users have permission to create/remove/list keyspaces.
** This map would be persisted in the "system" keyspace, or in the Migrations keyspace in such a fashion that modifying permissions on one node ripples out to the rest
* Add a client interface method that allows adding/removing permissions in the global map (set_global_permissions ?)
----
Expected usecase, starting from an empty cluster, with authentication enabled:
# Set a password for a "super/root" user (that has been predefined in Cassandra by default) in an IAuthenticator specific way
# Super user authenticates in Thrift
# Super user gives more users permission to create/list/remove keyspaces via the proposed Thrift 'set_global_permissions' method
# Users authenticate via Thrift
# Users create/remove/list keyspaces
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 0005-Add-authorization-to-describe_keyspace-s-and-change-.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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.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
>
>
> 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: 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
> 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
>
>
> 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Evans updated CASSANDRA-1271:
----------------------------------
Reviewer: urandom
> 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ 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
On second though, let's handle changing the caching elsewhere.
Rebased for trunk.
> 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 0004-Make-SimpleAuthority-aware-of-the-keyspace-list-reso.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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ 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
> 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ 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: 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.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: 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 0004-Make-SimpleAuthority-aware-of-the-keyspace-list-reso.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
>
>
> 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 0005-Add-authorization-to-describe_keyspace-s-and-change-.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: 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 0004-Make-SimpleAuthority-aware-of-the-keyspace-list-reso.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: 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: 1271-v3.tgz
Rebased for trunk.
> 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 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
> 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.
[jira] Assigned: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood reassigned CASSANDRA-1271:
-----------------------------------
Assignee: Eric Evans
> 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, 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 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
>
>
> 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Description:
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.)
was:
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, MODIFY_SCHEMA | An individual keyspace: since this is the last entry in the current hierarchy, READ/WRITE apply recursively to ancestor _data_ of the keyspace, while FULL applies recursively to ancestor _schemas_ of the keyspace. |
(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.)
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.
Modify how permissions should be applied recursively to resources which don't receive authorize() calls.
> 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
>
>
> 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 0005-Add-authorization-to-describe_keyspace-s-and-change-.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
>
>
> 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.
[jira] Commented: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916127#action_12916127 ]
Hudson commented on CASSANDRA-1271:
-----------------------------------
Integrated in Cassandra #550 (See [https://hudson.apache.org/hudson/job/Cassandra/550/])
eliminate {READ,WRITE}_VALUE perms
Patch by eevans for CASSANDRA-1271
Add authorization to describe_keyspace(s) and change Thrift exceptions.
Patch by Stu Hood; reviewed by eevans for CASSANDRA-1271
Make SimpleAuthority aware of the keyspace list resource.
Patch by Stu Hood; reviewed by eevans for CASSANDRA-1271
Check for permissions to modify the keyspace list.
Patch by Stu Hood; reviewed by eevans for CASSANDRA-1271
Convert to List<Object> resources
Patch by Stu Hood; reviewed by eevans for CASSANDRA-1271
Rather than 3 ThreadLocals (sure to continue to expand), use 1.
Patch by Stu Hood; reviewed by eevans for CASSANDRA-1271
> 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: 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
> 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ 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
> Priority: Minor
> Fix For: 0.7.0
>
> Attachments: 0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: 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
> 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
>
>
> 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.
[jira] Issue Comment Edited: (CASSANDRA-1271) Improve permissions
to allow control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903770#action_12903770 ]
Stu Hood edited comment on CASSANDRA-1271 at 8/28/10 1:33 AM:
--------------------------------------------------------------
0001 - Rather than 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?)
was (Author: stuhood):
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.
[jira] Commented: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 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
> 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Description:
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, MODIFY_SCHEMA | An individual keyspace: since this is the last entry in the current hierarchy, READ/WRITE apply recursively to ancestor _data_ of the keyspace, while FULL applies recursively to ancestor _schemas_ of the keyspace. |
(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.)
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.
was:
Once 1237 is completed, we'd like to improve AccessLevels so that they can be applied to the global scope, instead of just individual keyspaces.
Steps for this ticket:
* Improve/replace the AccessLevel structure to be more like a set of boolean permissions, rather than being level based
* Store a global map of (users/groups)->AccessLevel that will define which users have permission to create/remove/list keyspaces.
** This map would be persisted in the "system" keyspace, or in the Migrations keyspace in such a fashion that modifying permissions on one node ripples out to the rest
* Add a client interface method that allows adding/removing permissions in the global map (set_global_permissions ?)
----
Expected usecase, starting from an empty cluster, with authentication enabled:
# Set a password for a "super/root" user (that has been predefined in Cassandra by default) in an IAuthenticator specific way
# Super user authenticates in Thrift
# Super user gives more users permission to create/list/remove keyspaces via the proposed Thrift 'set_global_permissions' method
# Users authenticate via Thrift
# Users create/remove/list keyspaces
Overhaul for the change in direction on 1237.
> 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
>
>
> 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, MODIFY_SCHEMA | An individual keyspace: since this is the last entry in the current hierarchy, READ/WRITE apply recursively to ancestor _data_ of the keyspace, while FULL applies recursively to ancestor _schemas_ of the keyspace. |
> (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.)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ 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
Rebase for trunk.
> 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, 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.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow
control over creation/removal/listing of Keyspaces
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Attachment: (was: 0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.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.