You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Aleksey Yeschenko (JIRA)" <ji...@apache.org> on 2012/10/30 04:48:12 UTC
[jira] [Created] (CASSANDRA-4874) Possible authorizaton handling
impovements
Aleksey Yeschenko created CASSANDRA-4874:
--------------------------------------------
Summary: Possible authorizaton handling impovements
Key: CASSANDRA-4874
URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.2.0 beta 1, 1.1.6
Reporter: Aleksey Yeschenko
I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
Inconsistencies:
- CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
- BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
- DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
- DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
Other issues/suggestions
- CQL2 DROP INDEX should require authorization
- current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
(ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
- we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
- currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
- currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
keyspaces without an explicit permission for each of them.
- same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
- since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-4874:
-----------------------------------------
Attachment: warn-authority.txt
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, 4874-v4.txt, remove-consistency-vestigest-cqlsh-and-cqlg.txt, v1-v2.diff, warn-authority.txt
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500294#comment-13500294 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
As for IResource and functions - my idea was that each resource type will have its own root (no common global root). DataResources start with 'data', FunctionResources will be represented as 'functions[/..]. So there will usually be at least two levels independent of the resource type. This might even allow user-specified resource types as long as they follow the convention and as long as we have a map root name -> resource class.
So I vote for leaving IResource alone.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488052#comment-13488052 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
{quote}
bq.DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
Seems obvious.
{quote}
Not to me. Should be P.DELETE in Thrift and CQL3? If so, then what do you think about requiring both P.UPDATE and P.DELETE for inserts/updates with TTL set?
{quote}
bq. We should move it to one place. SomeClassWithABetterName.authorize
I'm not sure this really improves things, you've just created an abstraction layer with different names but fundamentally you still have to insert the correct auth call in each query processing path.
{quote}
You are right. This won't be needed once we fix permission inheritance. Then one method in ClientState (modified current hasAccees) will be sufficient. No need for another enum.
[~jbellis] Can you look at CASSANDRA-4875 as well please?
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501949#comment-13501949 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
I previously did overthink 2.2 in https://issues.apache.org/jira/browse/CASSANDRA-4874?focusedCommentId=13500289&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13500289
It's not really an escalation - these two users will still be limited to the permissions they collectively own. So 2.2 should actually work.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503593#comment-13503593 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
Not to self: one authentication rewrite is complete, make sure to:
1) Validate user existence in GRANT/REVOKE/LIST PERMISSIONS
2) Call IAuthority#revokeAll(String droppedUser) when a user is dropped
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, 4874-v4.txt, remove-consistency-vestigest-cqlsh-and-cqlg.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488826#comment-13488826 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
Also, if we are getting rid of P.DELETE in favor of one unified permission for insert/update/delete, then I'd rather add some new name that won't match any of the operations, to avoid confusion. Say, P.MODIFY.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-4874:
-----------------------------------------
Assignee: Aleksey Yeschenko
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500315#comment-13500315 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
bq. Of course you'd need to revoke GRANT as well. Works as designed!
I don't like this design :( P.GRANT (P.AUTHORIZE) would be an equivalent of the old FULL_ACCESS, but on steroids. A super-permission that includes other permissions.
No, permissions should not intersect.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504433#comment-13504433 ]
Jonathan Ellis commented on CASSANDRA-4874:
-------------------------------------------
Looks good overall. A couple comments:
- Prefer just returning Permission.NONE|ALL instead of copyOf; copying makes me think that the original (or possibly the copy) should be mutable, which is not the case here
- Why the rewrite of DropIndexStatement?
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, 4874-v4.txt, remove-consistency-vestigest-cqlsh-and-cqlg.txt, v1-v2.diff, warn-authority.txt
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504739#comment-13504739 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
attached 'move-resource-on-to-iauthorizer.txt' that moves filtering on resource to IAuthorizer itself away from ListPermissionsStatement#execute.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, 4874-v4.txt, move-resource-on-to-iauthorizer.txt, remove-consistency-vestigest-cqlsh-and-cqlg.txt, v1-v2.diff, warn-authority.txt
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500337#comment-13500337 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
Also queries like "LIST ALTER PERMISSIONS ON data/ks" now won't show everybody capable of altering data/ks. Will have to list grant permissions as well (since a user with P.GRANT will be able to just give P.ALTER to himself at any moment).
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-4874:
-----------------------------------------
Fix Version/s: 1.2.0 rc1
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-4874:
-----------------------------------------
Attachment: 4874-v2.txt
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-4874:
-----------------------------------------
Reviewer: jbellis
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500114#comment-13500114 ]
Jonathan Ellis commented on CASSANDRA-4874:
-------------------------------------------
Looks pretty good to me. Comments:
- Should document what happened to IAuth/LegacyAuth in News
- grantOption feels like premature complexity to me -- why not just a single GRANT permission?
Nits:
- unrelated cqlsh cleanup should be separate.
- Not 100% sure that IResource is going to be useful in its present form (for e.g. functions) so I'd be inclined to just use DataResource everywhere for now, but it's probably okay the way it is for now.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13499524#comment-13499524 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
v2 is almost identical to v2 (differs by 2 lines, one of which is a comment).
This way it will work with SimpleAuthenticator.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501946#comment-13501946 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
Limiting it to the permissions you already have at least means that you won't be able to re-grant the revoked permission back to yourself on your own.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488736#comment-13488736 ]
Sylvain Lebresne commented on CASSANDRA-4874:
---------------------------------------------
bq. unless you have a null-column in the first place and only care about the column name
Not sure I follow.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488748#comment-13488748 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
Btw I'm not advocating for keeping P.DELETE, just saying that there is sometimes a difference from security standpoint.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-4874:
-----------------------------------------
Attachment: 4874-v3.txt
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501925#comment-13501925 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
I probably am. I'll think about it.
But, to clarify - by LIST you meant ALTER, right?
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501936#comment-13501936 ]
Jonathan Ellis commented on CASSANDRA-4874:
-------------------------------------------
To match your example, yes.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500290#comment-13500290 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
So WITH GRANT OPTION is here to stay. It's simple to understand and doesn't leak permissions.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501945#comment-13501945 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
This will allow to get rid of grantOption and the permission checks in grant() and authorize() in IAuthority implementations. I'll just add two checks to grant statement and revokestatement: hasAccess(AUTHORIZE, resource) and hasAccees(permissiionToBeGratnedOrRevoked, resource).
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4874) Possible authorizaton
handling impovements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501917#comment-13501917 ]
Jonathan Ellis edited comment on CASSANDRA-4874 at 11/21/12 12:37 PM:
----------------------------------------------------------------------
You're overthinking it. You still have that problem with fine-grained grant, it's just more complex. Nor does "include user with GRANT as a user with LIST" make sense, because if you want to include users who could POTENTIALLY have LIST, well, a user with GRANT can give LIST to anyone, not just himself.
was (Author: jbellis):
You're overthinking it. You still have that problem with fine-grained grant, it's just more complex. Nor does "include user with GRANT as a user with LIST" make sense, because if you want to include users who could POTENTIALLY have grant, well, a user with GRANT can give LIST to anyone, not just himself.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-4874:
-----------------------------------------
Attachment: move-resource-on-to-iauthorizer.txt
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, 4874-v4.txt, move-resource-on-to-iauthorizer.txt, remove-consistency-vestigest-cqlsh-and-cqlg.txt, v1-v2.diff, warn-authority.txt
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488714#comment-13488714 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
bq. I don't see the difference between updating a value with crap or deleting it
Most time there is no difference, unless you have a null-column in the first place and only care about the column name.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13499571#comment-13499571 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
v3: Pulled out NativeAuthority. Still, please have a look at it while reviewing the issue - it might explain some implementation decisions.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501939#comment-13501939 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
[~jbellis]
Now I do think you are more right than I am.
What do you think about this option: introduce Permission.AUTHORIZE. Let users with AUTHORIZE on a resource GRANT and REVOKE permissions on that resource to/from others, but only the permissions they already have (on that resource or its parent, recursively), including AUTHORIZE itself? I considered this before, but I did overthink it back then.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500281#comment-13500281 ]
Jonathan Ellis commented on CASSANDRA-4874:
-------------------------------------------
bq. I assume having P.GRANT would give a user ability to grant and revoke any permission on the resource (including P.GRANT itself)
Right.
bq. The idea was to avoid breaking IAuthority interface in the future
That makes sense.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-4874:
-----------------------------------------
Attachment: v1-v2.diff
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-4874:
-----------------------------------------
Attachment: 4874-v4.txt
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, 4874-v4.txt, remove-consistency-vestigest-cqlsh-and-cqlg.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488104#comment-13488104 ]
Jonathan Ellis commented on CASSANDRA-4874:
-------------------------------------------
bq. Should be P.DELETE in Thrift and CQL3?
Yes.
bq. If so, then what do you think about requiring both P.UPDATE and P.DELETE for inserts/updates with TTL set?
Yes, we should. (This is why I'm not 100% sure it makes sense to distinguish between UPDATE and DELETE at all, but "require both for ttl" is probably the best compromise.)
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488562#comment-13488562 ]
Sylvain Lebresne commented on CASSANDRA-4874:
---------------------------------------------
bq. I'm not 100% sure it makes sense to distinguish between UPDATE and DELETE at all
I'd agree with that. From a security perspective I don't see the difference between updating a value with crap or deleting it, so imo both permission will always be set together and so it seems to me that having both only help people at making the mistake of revoking one permission without the other. Just my 2 cents though.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504741#comment-13504741 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
bq. Prefer just returning Permission.NONE|ALL instead of copyOf; copying makes me think that the original (or possibly the copy) should be mutable, which is not the case here
This is only the case with SimpleAuthorizer. The old IAuthority had authorize() return a EnumSet and Permission.ALL|NONE don't return a EnumSet anymore (EnumsSet is mutable). copyOf is there to convert Set<Permission> to EnumSet<Permission>.
bq. Why the rewrite of DropIndexStatement?
There used to be no way to get the CF from DropIndexStatement and I needed one to do a permission check for DROP INDEX (alter on parent cf). Now there is a way, but that required a rewrite.
bq. Do we want to support "show me all the permissions that have been granted to object X?"
We do, of cource. The latest (last?) patch makes this more explicit.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, 4874-v4.txt, move-resource-on-to-iauthorizer.txt, remove-consistency-vestigest-cqlsh-and-cqlg.txt, v1-v2.diff, warn-authority.txt
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488745#comment-13488745 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
Imagine a wide row representing a time series, where every column's name is a timestamp and every column's value is already null - you don't care about the value. In this case there is a difference between overwriting the value with crap (doesn't matter) and removing the column entirely (matters).
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504265#comment-13504265 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
Attached 'warn-authority.txt' patch that
1. Prints a warning on startup if it detects 'authority' param
2. Throws ConfigurationException if 'authority' isn't set to 'AllowAllAuthority'
This way upgrading users who didn't care about authorization in the first place won't have to update anything.
This is friendlier than just exiting, but I'm not 100% sure if we should be friendly. Not 100% but pretty sure still.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, 4874-v4.txt, remove-consistency-vestigest-cqlsh-and-cqlg.txt, v1-v2.diff, warn-authority.txt
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500327#comment-13500327 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
It's a meta-permission really (permission to grant permissions). It just doesn't belong there.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-4874:
-----------------------------------------
Attachment: remove-consistency-vestigest-cqlsh-and-cqlg.txt
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, 4874-v4.txt, remove-consistency-vestigest-cqlsh-and-cqlg.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503591#comment-13503591 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
v3 vs. v4 changes:
- moved cqlsh and Cql.g cleanup to a separate patch (remove-consistency-vestigest-cqlsh-and-cqlg.txt) - apply it first
- renamed IAuthority to IAuthorizer to be consistent with IAuthenticator
- renamed {AllowAll,Simple,Legacy}Authority to *Authorizer
- Permission.AUTHORIZE replaced WITH GRANT OPTION
- CREATE KEYSPACE now requires CREATE on ALL KEYSPACES (used to require CREATE on the not-yet-existing keyspace)
- CREATE TABLE now requires CREATE on the parent keyspace (used to require CREATE on the not-yet-existing table)
- new IAuthorizer.revokeAll(IResource droppedResource) method is called for cleanup when a keyspace/table gets dropped
- IAuthorizer.protectedResources now returns a set of IResource, not DataResource (future-proofing the interface)
- QueryProcessor.processStatement() now calls validate() first and then checkAccess() (used to be the other way around)
- GRANT, REVOKE and LIST all check the existence of the resource in question (boolean exists() method has been added to IResource)
- updated NEWS.txt
- modified CQL3 syntax (cqlsh autocompletion has been updated as well)
The new CQL3 statements:
- LIST { ALL [PERMISSIONS] | <perm> [PERMISSION] } [OF <user>]
- LIST { ALL [PERMISSIONS] | <perm> [PERMISSION] } ON ALL KEYSPACES [OF <user>] [NORECURSIVE]
- LIST { ALL [PERMISSIONS] | <perm> [PERMISSION] } ON KEYSPACE <keyspace> [of <user>] [NORECURSIVE]
- LIST { ALL [PERMISSIONS] | <perm> [PERMISSION] } ON [TABLE] [<keyspace>.]<table> [of <user>] [NORECURSIVE]
- GRANT { ALL [PERMISSIONS] | <perm> [PERMISSION] } ON ALL KEYSPACES TO <user>
- GRANT { ALL [PERMISSIONS] | <perm> [PERMISSION] } ON KEYSPACE <keyspace> TO <user>
- GRANT { ALL [PERMISSIONS] | <perm> [PERMISSION] } ON [TABLE] [<keyspace>.]<table> TO <user>
- REVOKE { ALL [PERMISSIONS] | <perm> [PERMISSION] } ON ALL KEYSPACES FROM <user>
- REVOKE { ALL [PERMISSIONS] | <perm> [PERMISSION] } ON KEYSPACE <keyspace> FROM <user>
- REVOKE { ALL [PERMISSIONS] | <perm> [PERMISSION] } ON [TABLE] [<keyspace>.]<table> FROM <user>
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, 4874-v4.txt, remove-consistency-vestigest-cqlsh-and-cqlg.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504438#comment-13504438 ]
Jonathan Ellis commented on CASSANDRA-4874:
-------------------------------------------
Do we want to support "show me all the permissions that have been granted to object X?"
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, 4874-v4.txt, remove-consistency-vestigest-cqlsh-and-cqlg.txt, v1-v2.diff, warn-authority.txt
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13487476#comment-13487476 ]
Jonathan Ellis commented on CASSANDRA-4874:
-------------------------------------------
bq. CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
CQL2 sounds correct to me, how can you have permissions on an object that doesn't exist yet?
But that would imply that KS create permissioning is also broken, which you mention.
Maybe we should have a "cluster" or "all" top-level permission: having create on all, allows creating keyspaces. This would fit with the heirarchy design you describe too (GRANT UPDATE ON ALL TO foo), and gives a nice shorthand for granting system-wide permissions (or a subset of them) w/o making someone a superuser.
bq. BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
ISTM that the correct behavior is to permission-check each statement in the batch separately.
bq. DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
Seems obvious.
bq. DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
ALTER sounds reasonable.
bq. We should move it to one place. SomeClassWithABetterName.authorize
I'm not sure this really improves things, you've just created an abstraction layer with different names but fundamentally you still have to insert the correct auth call in each query processing path.
bq. P.UPDATE on the KS should allow you to do updates on KS's cfs
+1
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504753#comment-13504753 ]
Jonathan Ellis commented on CASSANDRA-4874:
-------------------------------------------
+1
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, 4874-v4.txt, move-resource-on-to-iauthorizer.txt, remove-consistency-vestigest-cqlsh-and-cqlg.txt, v1-v2.diff, warn-authority.txt
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502042#comment-13502042 ]
Jonathan Ellis commented on CASSANDRA-4874:
-------------------------------------------
bq. Limiting it to the permissions you already have at least means that you won't be able to re-grant the revoked permission back to yourself on your own.
Makes sense to me.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500289#comment-13500289 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
Actually, that wouldn't work (a single GRANT permission).
I looked at two options, but both don't work:
1. Allow GRANT owners GRANT and REVOKE any permission on the resource (even those they don't have) - now we get the old FULL_ACCESS and all the associated problems (you have to check for GRANT and not just the requested permission and, secondly, REVOKE <perm> won't work as expected if a user still has GRANT permission on the resource).
2. Allow GRANT owners GRANT and REVOKE only the permissions they already have on the resource. This one is trickier:
2.1 Make P.GRANT non-recursive (disallow granting P.GRANT). Now you need to involve a superuser every time you want to allow someone grant permissions. This is bad since it involves superusers unnecessarily.
2.2 Make P.GRANT recursive (allow granting P.GRANT). Now we've got ourselves easy permission escalation. User A has every permission but P.GRANT. User B has P.SELECT and P.GRANT (or just P.GRANT). User B grants P.GRANT to user A. A grants B every permission he has. Now the two of them together have more permissions than the sum of their old ones.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501917#comment-13501917 ]
Jonathan Ellis commented on CASSANDRA-4874:
-------------------------------------------
You're overthinking it. You still have that problem with fine-grained grant, it's just more complex. Nor does "include user with GRANT as a user with LIST" make sense, because if you want to include users who could POTENTIALLY have grant, well, a user with GRANT can give LIST to anyone, not just himself.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4874) Possible authorizaton
handling impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13499524#comment-13499524 ]
Aleksey Yeschenko edited comment on CASSANDRA-4874 at 11/17/12 9:28 PM:
------------------------------------------------------------------------
v2 is almost identical to v1 (differs by 2 lines, one of which is a comment).
This way it will work with SimpleAuthenticator.
was (Author: iamaleksey):
v2 is almost identical to v2 (differs by 2 lines, one of which is a comment).
This way it will work with SimpleAuthenticator.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500303#comment-13500303 ]
Jonathan Ellis commented on CASSANDRA-4874:
-------------------------------------------
bq. REVOKE <perm> won't work as expected if a user still has GRANT permission on the resource).
Of course you'd need to revoke GRANT as well. Works as designed!
bq. I vote for leaving IResource alone
WFM.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500134#comment-13500134 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
BTW unfortunately just replacing "implements IAuthority" with "extends LegacyAuthority" won't be enough if a particular implementation used Permission.ALL and/or Permission.NONE. They were returning (mutable) EnumSet-s and I had to replace them with ImmutableSet-s. I wish there was an immutable subclass of EnumSet, but there isn't, because Java. That's the only issue though.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488770#comment-13488770 ]
Sylvain Lebresne commented on CASSANDRA-4874:
---------------------------------------------
Ok, I understand that example. It's a fairly specific use case imo (in term of security I mean), and there will always been cases where whatever permissions we allow won't be precise enough for someone. I'm still of the opinion that it's not worth the potential foot shooting of setting P.DELETE without P.UPDATE by mistake, but that's just an opinion.
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-4874:
-----------------------------------------
Attachment: 4874-4875.txt
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
impovements
Posted by "Aleksey Yeschenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500128#comment-13500128 ]
Aleksey Yeschenko commented on CASSANDRA-4874:
----------------------------------------------
Thanks.
bq. Should document what happened to IAuth/LegacyAuth in News
Will do.
bq. grantOption feels like premature complexity to me – why not just a single GRANT permission?
I assume having P.GRANT would give a user ability to grant and revoke any permission on the resource (including P.GRANT itself). This would also simplify grant and revoke implementations (check for P.GRANT and that's all). If so then I agree and I like it.
bq. unrelated cqlsh cleanup should be separate.
Sorry. Couldn't resist.
bq. Not 100% sure that IResource is going to be useful in its present form (for e.g. functions) so I'd be inclined to just use DataResource everywhere for now, but it's probably okay the way it is for now.
The idea was to avoid breaking IAuthority interface in the future. Hence the only assumptions were that any new resource type will be hierarchical, and every level will have a printable name. TBH I don't have a strong opinion on this point. We can just see what happens (if?) to functions/triggers/what not and if necessary slightly alter IAuthority in 1.3/1.4. It's YAGNI vs. not breaking stuff. Just using DataResource everywhere for now is fine by me. A second opinion maybe?
> Possible authorizaton handling impovements
> ------------------------------------------
>
> Key: CASSANDRA-4874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4874
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6, 1.2.0 beta 1
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Labels: security
> Fix For: 1.2.0 rc1
>
> Attachments: 4874-4875.txt, 4874-v2.txt, 4874-v3.txt, v1-v2.diff
>
>
> I'll create another issue with my suggestions about fixing/improving IAuthority interfaces. This one lists possible improvements that aren't related to grant/revoke methods.
> Inconsistencies:
> - CREATE COLUMNFAMILY: P.CREATE on the KS in CQL2 vs. P.CREATE on the CF in CQL3 and Thrift
> - BATCH: P.UPDATE or P.DELETE on CF in CQL2 vs. P.UPDATE in CQL3 and Thrift (despite remove* in Thrift asking for P.DELETE)
> - DELETE: P.DELETE in CQL2 and Thrift vs. P.UPDATE in CQL3
> - DROP INDEX: no checks in CQL2 vs. P.ALTER on the CF in CQL3
> Other issues/suggestions
> - CQL2 DROP INDEX should require authorization
> - current permission checks are inconsistent since they are performed separately by CQL2 query processor, Thrift CassandraServer and CQL3 statement classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operation, KS, CF, User), where operation would be a enum
> (ALTER_KEYSPACE, ALTER_TABLE, CREATE_TABLE, CREATE, USE, UPDATE etc.), CF should be nullable.
> - we don't respect the hierarchy when checking for permissions, or, to be more specific, we are doing it wrong. take CQL3 INSERT as an example:
> we require P.UPDATE on the CF or FULL_ACCESS on either KS or CF. However, having P.UPDATE on the KS won't allow you to perform the statement, only FULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE on the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocation-in-cassandra-1-1 point to it being a bug, since REVOKE UPDATE ON ks FROM omega is there.
> - currently we lack a way to set permission on cassandra/keyspaces resource. I think we should be able to do it. See the following point on why.
> - currently to create a keyspace you must have a P.CREATE permission on that keyspace THAT DOESN'T EVEN EXIST YET. So only a superuser can create a keyspace,
> or a superuser must first grant you a permission to create it. Which doesn't look right to me. P.CREATE on cassandra/keyspaces should allow you to create new
> keyspaces without an explicit permission for each of them.
> - same goes for CREATE TABLE. you need P.CREATE on that not-yet-existing CF of FULL_ACCESS on the whole KS. P.CREATE on the KS won't do. this is wrong.
> - since permissions don't map directly to statements, we should describe clearly in the documentation what permissions are required by what cql statement/thrift method.
> Full list of current permission requirements: https://gist.github.com/3978182
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira