[
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
