Return-Path: 
 <commits-return-151524-apmail-cassandra-commits-archive=cassandra.apache.org@cassandra.apache.org>
X-Original-To: apmail-cassandra-commits-archive@www.apache.org
Delivered-To: apmail-cassandra-commits-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 4823C18DD1
	for <apmail-cassandra-commits-archive@www.apache.org>;
 Tue, 10 Nov 2015 16:07:11 +0000 (UTC)
Received: (qmail 28271 invoked by uid 500); 10 Nov 2015 16:07:11 -0000
Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org
Received: (qmail 28240 invoked by uid 500); 10 Nov 2015 16:07:11 -0000
Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:commits-help@cassandra.apache.org>
List-Unsubscribe: <mailto:commits-unsubscribe@cassandra.apache.org>
List-Post: <mailto:commits@cassandra.apache.org>
List-Id: <commits.cassandra.apache.org>
Reply-To: dev@cassandra.apache.org
Delivered-To: mailing list commits@cassandra.apache.org
Received: (qmail 28214 invoked by uid 99); 10 Nov 2015 16:07:11 -0000
Received: from arcas.apache.org (HELO arcas) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Nov 2015 16:07:11 +0000
Received: from arcas.apache.org (localhost [127.0.0.1])
	by arcas (Postfix) with ESMTP id EA3E42C1F58
	for <commits@cassandra.apache.org>; Tue, 10 Nov 2015 16:07:10 +0000 (UTC)
Date: Tue, 10 Nov 2015 16:07:10 +0000 (UTC)
From: "Adam Holmberg (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12908005.1445884670000.28551.1447171630956@Atlassian.JIRA>
In-Reply-To: <JIRA.12908005.1445884670000@Atlassian.JIRA>
References: <JIRA.12908005.1445884670000@Atlassian.JIRA>
 <JIRA.12908005.1445884670480@arcas>
Subject: [jira] [Commented] (CASSANDRA-10594) Inconsistent permissions
 results return
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/CASSANDRA-10594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998819#comment-14998819 ] 

Adam Holmberg commented on CASSANDRA-10594:
-------------------------------------------

bq. The drivers are pretty good at changing this type of behavior based on the protocol version in use, so I don't think this would be problematic for them.
I don't even view this as a protocol issue -- it's more like a contract for what type of result message comes back from this CQL statement. The drivers make no assumptions about that. It's just confusing for integrators who can get either void or rows for the same query. Not that big a deal, just thought it was worth pointing out the inconsistency

> Inconsistent permissions results return
> ---------------------------------------
>
>                 Key: CASSANDRA-10594
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10594
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Adam Holmberg
>            Assignee: Sam Tunnicliffe
>            Priority: Minor
>
> The server returns inconsistent results when listing permissions, depending on whether a user is configured.
> *Observed with Cassandra 3.0:*
> Only super user configured:
> {code}
> cassandra@cqlsh> list all;
>  role | resource | permissions
> ------+----------+-------------
> (0 rows)
> {code}
> VOID result type is returned (meaning no result meta is returned and cqlsh must use the table meta to determine columns)
> With one user configured, no grants:
> {code}
> cassandra@cqlsh> create user holmberg with password 'tmp';
> cassandra@cqlsh> list all;
> results meta: system_auth permissions 4
>  role      | username  | resource    | permission
> -----------+-----------+-------------+------------
>  cassandra | cassandra | <role holmberg> |      ALTER
>  cassandra | cassandra | <role holmberg> |       DROP
>  cassandra | cassandra | <role holmberg> |  AUTHORIZE
> (3 rows)
> {code}
> Now a ROWS result message is returned with the cassandra super user grants. 
> Dropping the regular user causes the VOID message to be returned again.
> *Slightly different behavior on 2.2 branch:* VOID message with no result meta is returned, even if regular user is configured, until permissions are added to that user.
> *Expected:*
> It would be nice if the query always resulted in a ROWS result, even if there are no explicit permissions defined. This would provide the correct result metadata even if there are no rows.
> Additionally, it is strange that the 'cassandra' super user only appears in the results when another user is configured. I would expect it to always appear, or never.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)