[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17632229#comment-17632229
]
Sam Tunnicliffe commented on CASSANDRA-18018:
---------------------------------------------
bq. Granting ALL PERMISSIONS to newly created role / user (event if it is
SUPERUSER) by default for all possible resources sounds like a big no-no from
security standpoint.
Really? This actually seems like the textbook definition of a superuser. From
the Postgres docs[1], for example:
bq. A database superuser bypasses all permission checks, except the right to
log in. This is a dangerous privilege and should not be used carelessly; it is
best to do most of your work as a role that is not a superuser. To create a new
database superuser, use CREATE ROLE name SUPERUSER. You must do this as a role
that is already a superuser.
I think that the confusion here mainly stems from the fact that superusers (in
C* as in pgsql) _implicitly_ acquire ALL PERMISSIONS, because authz checks are
bypassed for them, whereas LIST PERMISSIONS and the system table which backs it
in the default implementation is concerned with _explicitly_ granted
permissions.
bq. 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.
If we did not explicitly add permissions that are directly granted to a
superuser, then what would happen if the superuser status were removed? One
might think that if a user has been explicitly granted access to some resource,
they should retain it in the event that they lose their implicit access to all
(other) resources. It might be simple enough to work around this by
automatically adding {{ALL PERMISSIONS}} on the root of each resource type
({{<all roles>}}, {{<all keyspaces>}} etc) to a role created with or given
superuser status. However, it is also possible (though not advisable) for those
permissions to be explicitly granted, so we would still have the problem of
retaining some vs all of them if superuser status is removed.
bq. When we query the "system_auth.role_permissions" table, entries for
"superuser_joe" are updated as expected regarding the new keyspace. However,
there is no expected entries regarding permissions on ALL ROLES resource.
This is consistent with the above point regarding explicit vs implicit
permissions, along the automatic granting of permissions to creators of
database resources (tables, keyspaces, functions, roles, etc) (CASSANDRA-7216).
So when your user, which happens to have the superuser attribute, creates a
table it aquires all permissions on that table. If the superuser status was
withdrawn, should the user lose those permissions? Probably not, so they are
recorded in the relevant system table.
Regarding documentation, the DataStax docs are externally maintained and don't
fall under the purview of the ASF project. The official are a bit more
current/accurate, but they too are definitely a somewhat lacking detail in this
area.
[1] https://www.postgresql.org/docs/15/role-attributes.html
> 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
> Priority: Normal
> Labels: lhf
>
> 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]
