Thanks everyone for comments. I would like to close this discussion if there
are no further comments and continue with the PR for code changes. I prefer
‘LIST SUPERUSERS’ cql command, please let me know if you prefer different
command/option.
> On Mar 1, 2024, at 12:44 PM, Sam Tunnicliffe wr
>Regarding removal of inheriting superuser role needs broader discussion. There
>must be a reason why it was done and removing this feature may impact existing
>use cases.
The reason behind the current behaviour is almost irrelevant, the fact is that
this is the way that it works and has done s
- Forgot to mention, is_superuser of roles table cannot be altered as it is
just showing what is persisted in the table. We can think about changing super
column of LIST ROLES command instead.
- Regarding change of the underlying state while we retrieve superusers info, I
believe we do not need
- In the example you listed below, role2 doesn’t lose superuser status because
it was created as a superuser (based on the point 2). The scenario you
mentioned can happen if role2 was initially not created as a superuser. When we
create a role as a superuser, we persist that info in roles table,
Don’t know why is_superuser was not set to true for acquired superusers. Now if
we change it, may break existing tools/scripts/understanding of customers, so
do we want to update current understanding of is_superuser column or introduce
a new column or option instead?
> On Feb 29, 2024, at 11:
I believe that opens the door to this kind of situations:
1. create superuser role "role1"
2. create superuser role "role2"
3. add "role2" to members of "role1"
4. remove "role2" from the members of "role1"
5. "role2" now inexplicitly lost the superuser state
TBH, my preferred solution is making
Why don't we just update the is_superuser column of a role when it
effectively achieves a superuser status when it is granted some superuser
role? Similarly, we would remove its superuser status when there are no
superuser roles granted to it anymore.
I think that at least for the second case (whe
Hi Maxwell,
Currently system_auth.roles table doesn’t have acquired superuser info
available in columns to filter on it. Below is the system_auth.roles table for
the example I have listed in the previous email. If you notice, though role1
and role11 acquired superuser status through grants, is_
Hi ,
1. can this cql "SELECT role from system_auth.roles where is_superuser =
True ALLOW FILTERING ;" meet your needs if the user to execute the cql
have the right to do so ？
2. I think may be we can also add the ability to filter on list role/user
grammar, for example : list user where super =
Hi Team,
Currently LIST ROLES command doesn’t indicate if a role has superuser
privilege, if acquired through a grant in roles hierarchy (LIST ROLES has super
column true only if the role is created with SUPERUSER=true). For example, in
the below example, super1 is a superuser, role1 acquired s
10 matches
Mail list logo
