[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714568#comment-17714568
]
Sam Tunnicliffe commented on CASSANDRA-18018:
---------------------------------------------
The status quo is this:
1. Permissions and superuser privilege are distinct concepts.
2. Granting the {{SUPERUSER}} privilege to a role does not entail additional
permissions.
3. {{LIST PERMISSIONS}} in all of its variants gives users all the tools they
need to see the *permissions* that have been granted to a role (or all roles),
taking into account inheritance via hierarchies of both roles and resources.
4. {{LIST ROLES}} provides the information to show whether a *role* has
superuser status, taking into account the inheritance of roles.
Given the above, I disagree with the assertion that it's somehow more difficult
than it need be to figure out what a given user is entitled to do in the
database. I also disagree that what this JIRA proposes presents the information
more clearly. The more I think about this, the more I'm convinced that
conflating the two things in this way is a misstep and so I'm really not
inclined to approve changes along the lines of what's proposed here. Of course,
mine is just one voice, so if other committers *are* convinced by this
proposal, they can of course sign off on it. I wouldn't -1 such a decision.
That said, I think there are a couple of ways we could improve the ergonomics
if we really feel that it's necessary.
h2. Extend {{LIST ROLES}} to allow filtering based on attributes of the role(s)
The only limiting possible now is by the primary role. e.g. here {{user_1}} has
been granted {{{}super_1{}}}, which is reflected in:
{code:java}
cqlsh> LIST ROLES OF user_1 ;
role | super | login | options | datacenters
---------+-------+-------+---------+-------------
super_1 | True | False | {} | ALL
user_1 | False | True | {} | ALL
(2 rows)
{code}
It might be nice to support something like:
{code:java}
cqlsh> LIST ROLES OF user_1 WITH SUPERUSER;
role | super | login | options | datacenters
---------+-------+-------+---------+-------------
super_1 | True | False | {} | ALL
(1 rows)
{code}
h2. Add a new virtual table to lookup _effective_ permissions for the
combination of a role and resource.
This would simply delegate to the configured {{IAuthenticator}} so dealing with
and presenting the potentially complicated permutations of inherited roles,
resources, permissions and privileges should be straightforward. e.g.
{code:java}
cqlsh> select permission
from system_views.effective_permissions
where role = user_1
and resource = data/keyspace1/table1;
permission |
-------------
MODIFY
SELECT
ALTER
DROP
AUTHORIZE
(5 rows)
{code}
> List command output not correct for super user, after grant command
> -------------------------------------------------------------------
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
> Reporter: Shailaja Koppu
> Assignee: Maxim Chanturiay
> Priority: Normal
> Labels: lhf
> Fix For: 4.1.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> ----------------------------------------+-----------
> shaadmin1c1 | shaadmin1c1 | <table testk1.t1> | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> ------------------------------------------------------------------------------------------
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff0000}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
