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

Sam Tunnicliffe commented on CASSANDRA-10594:
---------------------------------------------

There are 2 things here; the VOID vs ROWS result message, and the 
(non-)appearance of rows in the results.

The first is simply a historical artifact. I can't say for sure why we decided 
to return a VOID result when there are no rows to display, but {{LIST 
PERMISSIONS}} has always done that, as has {{LIST USERS}}, and so {{LIST 
ROLES}} followed the precedent when introduced in 2.2. We could change such 
that a ROWS result is always returned, but whilst this wouldn't be a protocol 
change, it would be a change to expected, if undocumented, behaviour so we 
can't just go ahead and do it whenever. Under the tick-tock model, this would 
need to be targetted for 4.0, but you could even question whether it's worth it 
at all, even though it's a pain for cqlsh. 

The reason for what seems like inconsistent permissions being listed is that 
the {{cassandra}} role has superuser status which is effectively a role-level 
attribute, rather than a set of permissions. So before the additional user is 
created, there are indeed no permissions which have been granted to 
{{cassandra}}, and so the result of {{LIST ALL}} at that point is empty. When a 
user (or any other resource) is created though, we automatically grant 
'ownership' permissions to the role which created it, hence you then see the 
permissions on {{<role holmberg>}} granted to {{cassandra}} (see 
CASSANDRA-7216). This came in in 2.2. so I'm a bit puzzled by 

bq. 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.

and I can't reproduce this myself. Would you be able to detail the steps to 
repro this on 2.2?

Your example actually highlights another problem in that the grammar is way too 
permissive here, as {{LIST ALL}} shouldn't be valid without at least appending 
{{PERMISSIONS}}. IMO, the valid forms should be (assuming superuser status):

{code}
LIST ALL PERMISSIONS;
LIST ALL PERMISSIONS OF <role>;
LIST ALL PERMISSIONS ON <resource>;
LIST ALL PERMISSIONS ON <resource> OF <role>;
{code}

plus of course the variants which specify a single permission, rather than 
{{ALL}}. As with the first issue above, it's regrettable that this is the case, 
but realistically, I don't think we can fix it outside of a major 
(super-major?) release. 


> 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)

Reply via email to