[ 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