[jira] [Updated] (CASSANDRA-13053) GRANT/REVOKE on table without keyspace performs permissions check incorrectly

2017-03-07 Thread Aleksey Yeschenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-13053:
--
Fix Version/s: (was: 3.11.x)
   (was: 3.0.x)
   (was: 2.2.x)
   3.11.0
   3.0.13
   2.2.10

> GRANT/REVOKE on table without keyspace performs permissions check incorrectly
> -
>
> Key: CASSANDRA-13053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13053
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Sam Tunnicliffe
>Assignee: Aleksey Yeschenko
>Priority: Minor
> Fix For: 2.2.10, 3.0.13, 3.11.0
>
>
> 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  or any of its parents"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13053) GRANT/REVOKE on table without keyspace performs permissions check incorrectly

2017-03-07 Thread Aleksey Yeschenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-13053:
--
   Resolution: Fixed
Reproduced In: 3.10, 3.0.11, 2.2.9  (was: 2.2.9, 3.0.11, 3.10)
   Status: Resolved  (was: Ready to Commit)

> GRANT/REVOKE on table without keyspace performs permissions check incorrectly
> -
>
> Key: CASSANDRA-13053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13053
> 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  or any of its parents"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13053) GRANT/REVOKE on table without keyspace performs permissions check incorrectly

2017-03-07 Thread Sam Tunnicliffe (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-13053:

Status: Ready to Commit  (was: Patch Available)

> GRANT/REVOKE on table without keyspace performs permissions check incorrectly
> -
>
> Key: CASSANDRA-13053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13053
> 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  or any of its parents"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13053) GRANT/REVOKE on table without keyspace performs permissions check incorrectly

2017-02-28 Thread Aleksey Yeschenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-13053:
--
 Reviewer: Sam Tunnicliffe
Reproduced In: 3.10, 3.0.11, 2.2.9  (was: 2.2.9, 3.0.11, 3.10)
   Status: Patch Available  (was: In Progress)

> GRANT/REVOKE on table without keyspace performs permissions check incorrectly
> -
>
> Key: CASSANDRA-13053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13053
> 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  or any of its parents"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13053) GRANT/REVOKE on table without keyspace performs permissions check incorrectly

2017-02-28 Thread Aleksey Yeschenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-13053:
--
Priority: Minor  (was: Major)

> GRANT/REVOKE on table without keyspace performs permissions check incorrectly
> -
>
> Key: CASSANDRA-13053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13053
> 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  or any of its parents"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)