cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13053) GRANT/REVOKE on table without keyspace performs permissions check incorrectly
Date Tue, 28 Feb 2017 18:29:45 GMT


Aleksey Yeschenko commented on CASSANDRA-13053:


Simple patch attached (2.2 merges cleanly upwards). Will kick off a basic CI run and write
up a quick unit test in the meantime.

> GRANT/REVOKE on table without keyspace performs permissions check incorrectly
> -----------------------------------------------------------------------------
>                 Key: CASSANDRA-13053
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL
>            Reporter: Sam Tunnicliffe
>            Assignee: Aleksey Yeschenko
>            Priority: Minor
>             Fix For: 2.2.x, 3.0.x, 3.11.x
> When a {{GRANT}} or {{REVOKE}} statement is executed on a table without specifying the
keyspace, we attempt to use the client session's keyspace to qualify the resource. 
> This is done when validating the statement, which occurs after checking that the user
executing the statement has sufficient permissions. This means that the permissions checking
uses an incorrect resource, namely a table with a null keyspace. If that user is a superuser,
then no error is encountered as superuser privs implicitly grants *all* permissions. If the
user is not a superuser, then the {{GRANT}} or {{REVOKE}} fails with an ugly error, regardless
of which keyspace the client session is bound to:
> {code}
> Unauthorized: Error from server: code=2100 [Unauthorized] message="User admin has no
AUTHORIZE permission on <table null.t1> or any of its parents"
> {code}

This message was sent by Atlassian JIRA

View raw message