cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling impovements
Date Mon, 19 Nov 2012 10:28:58 GMT

    [ 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

Mime
View raw message