[
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
