Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 19 Nov 2012 10:28:58 +0000 (UTC)
From: "Aleksey Yeschenko (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <2049900701.2312.1353320938609.JavaMail.jiratomcat@arcas>
In-Reply-To: <1027293777.42669.1351568892551.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (CASSANDRA-4874) Possible authorizaton handling
 impovements
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-4874?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
13500128#comment-13500128 ]=20

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 =E2=80=93 why not jus=
t a single GRANT permission?
I assume having P.GRANT would give a user ability to grant and revoke any p=
ermission on the resource (including P.GRANT itself). This would also simpl=
ify 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 th=
e only assumptions were that any new resource type will be hierarchical, an=
d 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/wh=
at 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?
               =20
> 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 IAut=
hority 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 Thri=
ft (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 sep=
arately by CQL2 query processor, Thrift CassandraServer and CQL3 statement =
classes.
> We should move it to one place. SomeClassWithABetterName.authorize(Operat=
ion, 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 F=
ULL_ACCESS will do.
> I doubt this was intentional, and if it was, I say it's wrong. P.UPDATE o=
n the KS should allow you to do updates on KS's cfs.
> Examples in http://www.datastax.com/dev/blog/dynamic-permission-allocatio=
n-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 resour=
ce. 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 t=
hat 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 does=
n't look right to me. P.CREATE on cassandra/keyspaces should allow you to c=
reate 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 wro=
ng.
> - since permissions don't map directly to statements, we should describe =
clearly in the documentation what permissions are required by what cql stat=
ement/thrift method.
> Full list of current permission requirements: https://gist.github.com/397=
8182

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira