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, 26 Nov 2012 01:20:58 GMT

    [ 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

Mime
View raw message