Re: [VOTE] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

[shailajakoppu]

+1


> On 5 May 2023, at 11:44 am, Sam Tunnicliffe  wrote:
> 
> +1
> 
>> On 4 May 2023, at 17:46, Doug Rohrer  wrote:
>> 
>> Hello all,
>> 
>> I’d like to put CEP-28 to a vote.
>> 
>> Proposal:
>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics
>>  
>> 
>> 
>> Jira:
>> https://issues.apache.org/jira/browse/CASSANDRA-16222 
>> 
>> 
>> Draft implementation:
>> 
>> - Apache Cassandra Spark Analytics source code: 
>> https://github.com/frankgh/cassandra-analytics 
>> 
>> - Changes required for Sidecar: 
>> https://github.com/frankgh/cassandra-sidecar/tree/CEP-28-bulk-apis 
>> 
>> 
>> Discussion:
>> https://lists.apache.org/thread/lrww4d7cdxgtg8o3gt8b8foymzpvq7z3 
>> 
>> 
>> The vote will be open for 72 hours. 
>> A vote passes if there are at least three binding +1s and no binding vetoes. 
>> 
>> 
>> Thanks,
>> 
>> Doug Rohrer
>> 
>> 
> 

Re: [Discuss] CQLSH should left-align numbers, right-align text (CASSANDRA-19150)

[shailajakoppu]

Hi Brad,

While I prefer the indentation style that Postgres following for better 
readability of text, if we are changing it, this may break existing scripts of 
users/operators if tightly coupled with the current format/spaces etc (Ideally 
shouldn’t be, but as Cassandra being used all over the world, such scenarios 
are possible). To avoid breaking such existing scripts, I believe either these 
changes need to happen in a major release or under a feature flag (which can be 
deprecated over the time), for existing scripts to continue without breaking 
until they are fixed.

Thanks,
Shailaja


> On Jan 9, 2024, at 5:23 PM, Derek Chen-Becker  wrote:
> 
> Actually, now that I'm looking at the original email on my browser and not my 
> phone (and can see the formatting properly), I think we have the nomenclature 
> backward here. Left-alignment in the printing world means that text in each 
> cell starts at the left-most column for the cell, but in your examples you're 
> calling that right-aligned (and vice-versa). Along the lines of what Stefan 
> said, I think this probably came about more as a "we'll just keep things 
> simple and use the same alignment everywhere" rather than an intentional 
> right-alignment of text for a specific purpose. I would actually be fine with 
> left-aligning text to fit what appears to be standard practice in other 
> systems.
> 
> Cheers,
> 
> Derek
> 
> On Tue, Jan 9, 2024 at 7:34 AM Brad  > wrote:
>> CQLSH currently left-aligns all output, affecting both numbers and text.  
>> While this works well for numbers, a better approach adopted by many is to 
>> left align numbers and right align text.
>> 
>> For example, both Excel and Postgres shell use the later:
>> 
>> psql
>> # select * from employee;
>>  empid |  name   |dept
>> ---+-+
>>  1 | Clark   | Sales
>>200 | Dave| Accounting
>> 33 | Johnson | Sales
>> 
>> while CQLSH simply left aligns all the columns 
>> 
>> cqlsh> select * from employee;
>>  empid | dept   | name
>> ---++-
>> 33 |  Sales | Johnson
>>  1 |  Sales |   Clark
>>200 | Accounting |Dave
>> 
>> 
>> Left aligned text looks much worse on text values which share common prefixes
>> 
>> cqlsh> select * from system_views.system_properties limit 7 ;
>> 
>>  name   | value
>> +
>>   JAVA_HOME |  
>> /Users/brad/.jenv/versions/17
>>cassandra.jmx.local.port |
>>7199
>>cassandra.logdir | 
>> /usr/local/cassandra-5.0-beta1/bin/../logs
>>cassandra.storagedir | 
>> /usr/local/cassandra-5.0-beta1/bin/../data
>>   com.sun.management.jmxremote.authenticate |
>>   false
>>  com.sun.management.jmxremote.password.file |  
>> /etc/cassandra/jmxremote.password
>> io.netty.transport.estimateSizeOnSubmit |
>>   false
>> 
>> 
>> The Jira CASSANDRA-19150 
>>  discusses this in 
>> further detail with some additional examples.
>> 
>> I wanted to raise the issue here to propose changing CQLSH to right-align 
>> text while continue to left-align numbers.
>> 
>> Regards,
>> 
>> Brad Schoening
>> 
>>  
>> Reply
>> Forward
>> 
>> Add reaction
> 
> 
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
> 

Re: [DISCUSS] New CQL command/option for listing roles with superuser privileges

[shailajakoppu]

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_superuser column is 
False for these roles and acquired superuser status is not apparent directly 
from the columns of this table. member_of column shows immediate parent/grant 
of a given role. But these grants can result in a huge tree of roles hierarchy 
and there may be a role anywhere up in the hierarchy which is a superuser.

cassandra@cqlsh> select * from system_auth.roles;

 role  | can_login | is_superuser | member_of  | salted_hash
---+---+--++--
 role2 | False |False |   null |
 null
role11 | False |False |  {'role1'} |
 null
super1 | False | True |   null |
 null
 role1 | False |False | {'super1'} |
 null


Thanks,
Shailaja


> On Feb 29, 2024, at 2:11 AM, guo Maxwell  wrote:
> 
> 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 = True;
> 
> 
> 
> Shailaja Koppu mailto:s_ko...@apple.com>> 于2024年2月28日周三 
> 20:40写道：
>> 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 
>> superuser status through grant of super1 and role11 acquired superuser 
>> status through grant of role1. LIST ROLES output has super column true only 
>> for super1.
>> 
>> 
>> cassandra@cqlsh> create role super1 WITH SUPERUSER = true;
>> cassandra@cqlsh> create role role1;
>> cassandra@cqlsh> create role role11;
>> cassandra@cqlsh> create role role2;
>> cassandra@cqlsh> grant super1 to role1;
>> cassandra@cqlsh> grant role1 to role11;
>> cassandra@cqlsh> list roles;
>> 
>>  role  | super | login | options | datacenters
>> ---+---+---+-+-
>>  role1 | False | False |{} | ALL
>> role11 | False | False |{} | ALL
>>  role2 | False | False |{} | ALL
>> super1 |  True | False |{} | ALL
>> 
>> 
>> One way to check has a role acquired superuser status is by running LIST 
>> ROLES of  and looking for at least one row with super column true. 
>> This works fine to check superuser status of a given role.
>> 
>> cassandra@cqlsh> list roles of role11;
>> 
>>  role   | super | login | options | datacenters
>> +---+---+-+-
>>   role1 | False | False |{} | ALL
>>  role11 | False | False |{} | ALL
>>  super1 |  True | False |{} | ALL
>> 
>> 
>> But if we need to get list of all roles having superuser status (acquired 
>> through grant as well), there is no easy way to retrieve this from C*. This 
>> can be a requirement for an external service interacting with C* and 
>> performing their own checks (for example, Sidecar). So I am proposing a new 
>> CQL command LIST SUPERUSERS, which lists all roles having superuser status 
>> (acquired as well). We will ensure that the user running this command has 
>> DESCRIBE permission on root roles resource, i.e, to run this command user 
>> must be either a superuser or granted DESCRIBE permission on ALL ROLES. Here 
>> is the Jira  and 
>> sample output for the above example.
>> 
>> cassandra@cqlsh> list superusers;
>> 
>>  role
>> ---
>>  role1
>> role11
>> super1
>> 
>> Alternatives thought of so far, 
>> - LIST ROLES SUPERUSERSONLY
>> - LIST ROLES superuseronly=true
>> - LIST USERS superuseronly=true  command : I have a question here, is LIST 
>> USERS command deprecated? I see this link saying that 
>> https://docs.datastax.com/en/cql-oss/3.3/cql/cql_reference/cqlListUsers.html.
>>  if LIST USERS and LISR ROLES commands are same, why don’t we just pick one 
>> so we don’t have to maintain two different commands ?
>> - LIST ROLES command default i.e, without NORECURSIVE clause : to print 
>> super column true for acquired superusers as well, but this may break 
>> existing tools/scripts of customers as we are changing the defa

Re: [DISCUSS] New CQL command/option for listing roles with superuser privileges

[shailajakoppu]

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:30 AM, Štefan Miklošovič  
> wrote:
> 
> 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 (when a superuser role is revoked 
> and there is none anymore), there would need to be some transaction because 
> as it checks if there are any superuser roles or not to set it to false, 
> somebody else might grant that superuser role to it again so we might end up 
> with having is_superuser set to false while it might still have a superuser 
> role granted.
> 
> I am not sure if this is achievable and I am sorry if this was already 
> answered / rejected elsewhere.
> 
> On Thu, Feb 29, 2024 at 11:33 AM  > wrote:
>> 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_superuser 
>> column is False for these roles and acquired superuser status is not 
>> apparent directly from the columns of this table. member_of column shows 
>> immediate parent/grant of a given role. But these grants can result in a 
>> huge tree of roles hierarchy and there may be a role anywhere up in the 
>> hierarchy which is a superuser.
>> 
>> cassandra@cqlsh> select * from system_auth.roles;
>> 
>>  role  | can_login | is_superuser | member_of  | salted_hash
>> ---+---+--++--
>>  role2 | False |False |   null | 
>> null
>> role11 | False |False |  {'role1'} | 
>> null
>> super1 | False | True |   null | 
>> null
>>  role1 | False |False | {'super1'} | 
>> null
>> 
>> 
>> Thanks,
>> Shailaja
>> 
>> 
>>> On Feb 29, 2024, at 2:11 AM, guo Maxwell >> > wrote:
>>> 
>>> 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 = True;
>>> 
>>> 
>>> 
>>> Shailaja Koppu mailto:s_ko...@apple.com>> 于2024年2月28日周三 
>>> 20:40写道：
 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 
 superuser status through grant of super1 and role11 acquired superuser 
 status through grant of role1. LIST ROLES output has super column true 
 only for super1.
 
 
 cassandra@cqlsh> create role super1 WITH SUPERUSER = true;
 cassandra@cqlsh> create role role1;
 cassandra@cqlsh> create role role11;
 cassandra@cqlsh> create role role2;
 cassandra@cqlsh> grant super1 to role1;
 cassandra@cqlsh> grant role1 to role11;
 cassandra@cqlsh> list roles;
 
  role  | super | login | options | datacenters
 ---+---+---+-+-
  role1 | False | False |{} | ALL
 role11 | False | False |{} | ALL
  role2 | False | False |{} | ALL
 super1 |  True | False |{} | ALL
 
 
 One way to check has a role acquired superuser status is by running LIST 
 ROLES of  and looking for at least one row with super column 
 true. This works fine to check superuser status of a given role.
 
 cassandra@cqlsh> list roles of role11;
 
  role   | super | login | options | datacenters
 +---+---+-+-
   role1 | False | False |{} | ALL
  role11 | False | False |{} | ALL
  super1 |  True | False |{} | ALL
 
 
 But if we need to get list of all roles having superuser status (acquired 
 through gran

Re: [DISCUSS] New CQL command/option for listing roles with superuser privileges

[shailajakoppu]

- 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, i.e, a role 
doesn’t lose that state by removal of a grant. Whereas acquired superuser 
status is not persisted, it is calculated on they fly looking at each role in 
the hierarchy

- 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. So I believe we need a separate discussion just for that.


> On Feb 29, 2024, at 12:36 PM, Bowen Song via dev  
> wrote:
> 
> I believe that opens the door to this kind of situations:
> 
> create superuser role "role1"
> create superuser role "role2"
> add "role2" to members of "role1"
> remove "role2" from the members of "role1"
> "role2" now inexplicitly lost the superuser state
> TBH, my preferred solution is making superuser roles not inheritable. If a 
> role has members, it cannot be made superuser; and if a role is superuser, no 
> members can be added to it.
> 
> It doesn't make much sense to inherit from a superuser role, because it has 
> unrestricted permissions, which renders any permission explicitly set on the 
> child roles useless. This enforces the role to be made superuser explicitly, 
> which makes all the display or filtering issues related to the inheritance 
> goes away.
> 
> On 29/02/2024 11:30, Štefan Miklošovič wrote:
>> 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 (when a superuser role is revoked 
>> and there is none anymore), there would need to be some transaction because 
>> as it checks if there are any superuser roles or not to set it to false, 
>> somebody else might grant that superuser role to it again so we might end up 
>> with having is_superuser set to false while it might still have a superuser 
>> role granted.
>> 
>> I am not sure if this is achievable and I am sorry if this was already 
>> answered / rejected elsewhere.
>> 
>> On Thu, Feb 29, 2024 at 11:33 AM > > wrote:
>>> 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_superuser 
>>> column is False for these roles and acquired superuser status is not 
>>> apparent directly from the columns of this table. member_of column shows 
>>> immediate parent/grant of a given role. But these grants can result in a 
>>> huge tree of roles hierarchy and there may be a role anywhere up in the 
>>> hierarchy which is a superuser.
>>> 
>>> cassandra@cqlsh> select * from system_auth.roles;
>>> 
>>>  role  | can_login | is_superuser | member_of  | salted_hash
>>> ---+---+--++--
>>>  role2 | False |False |   null |
>>>  null
>>> role11 | False |False |  {'role1'} |
>>>  null
>>> super1 | False | True |   null |
>>>  null
>>>  role1 | False |False | {'super1'} |
>>>  null
>>> 
>>> 
>>> Thanks,
>>> Shailaja
>>> 
>>> 
 On Feb 29, 2024, at 2:11 AM, guo Maxwell >>> > wrote:
 
 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 = True;
 
 
 
 Shailaja Koppu mailto:s_ko...@apple.com>> 
 于2024年2月28日周三 20:40写道：
> 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 
> superuser status through grant of super1 and role11 acquired superuser 
> status through grant of role1. LIST ROLES output has super column true 
> only for sup

Re: [DISCUSS] New CQL command/option for listing roles with superuser privileges

[shailajakoppu]

- 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 a transaction for that, because it can happen to any 
column of almost any CQL query. For example, state of login/options/datacenters 
etc can also change while we are processing a query. From my understanding it’s 
acceptable that user runs the same query twice and sees difference in the 
output because of ongoing state changes. Caller if caching results of a CQL 
query, may rerun the query periodically to refresh their cache.



> On Mar 1, 2024, at 11:39 AM, shailajako...@icloud.com wrote:
> 
> 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:30 AM, Štefan Miklošovič 
>>  wrote:
>> 
>> 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 (when a superuser role is revoked 
>> and there is none anymore), there would need to be some transaction because 
>> as it checks if there are any superuser roles or not to set it to false, 
>> somebody else might grant that superuser role to it again so we might end up 
>> with having is_superuser set to false while it might still have a superuser 
>> role granted.
>> 
>> I am not sure if this is achievable and I am sorry if this was already 
>> answered / rejected elsewhere.
>> 
>> On Thu, Feb 29, 2024 at 11:33 AM > > wrote:
>>> 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_superuser 
>>> column is False for these roles and acquired superuser status is not 
>>> apparent directly from the columns of this table. member_of column shows 
>>> immediate parent/grant of a given role. But these grants can result in a 
>>> huge tree of roles hierarchy and there may be a role anywhere up in the 
>>> hierarchy which is a superuser.
>>> 
>>> cassandra@cqlsh> select * from system_auth.roles;
>>> 
>>>  role  | can_login | is_superuser | member_of  | salted_hash
>>> ---+---+--++--
>>>  role2 | False |False |   null |
>>>  null
>>> role11 | False |False |  {'role1'} |
>>>  null
>>> super1 | False | True |   null |
>>>  null
>>>  role1 | False |False | {'super1'} |
>>>  null
>>> 
>>> 
>>> Thanks,
>>> Shailaja
>>> 
>>> 
 On Feb 29, 2024, at 2:11 AM, guo Maxwell >>> > wrote:
 
 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 = True;
 
 
 
 Shailaja Koppu mailto:s_ko...@apple.com>> 
 于2024年2月28日周三 20:40写道：
> 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 
> superuser status through grant of super1 and role11 acquired superuser 
> status through grant of role1. LIST ROLES output has super column true 
> only for super1.
> 
> 
> cassandra@cqlsh> create role super1 WITH SUPERUSER = true;
> cassandra@cqlsh> create role role1;
> cassandra@cqlsh> create role role11;
> cassandra@cqlsh> create role role2;
> cassandra@cqlsh> grant super1 to role1;
> cassandra@cqlsh> grant role1 to role11;
> cassandra@cqlsh> list roles;
> 
>  role  | super | login | options | datacenters
> ---+---+---+-+-

Re: [DISCUSS] New CQL command/option for listing roles with superuser privileges

[shailajakoppu]

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  wrote:
> 
> >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 since its inception. I 
> implemented RBAC in the first place (CASSANDRA-7653) and I don't remember why 
> we chose to have superuser privilege inherited in this way, though with 
> hindsight I do agree with Bowen that perhaps it would have been better were 
> it not inheritable. Not to say that decisions can never be revisited, but we 
> all know that the cost of changing established behaviour in a database is 
> extremely high even during a major release and so is not something to be 
> undertaken lightly. 
> 
> The discussion here is also rather pre-occupied with the default 
> implementation and any changes to behaviour or semantics would need to 
> consider external/third party implementations. Any solution which involves 
> simply querying the system.roles table in some new way, or updating it 
> somehow differently only works for the default IRoleManager that ships with 
> C*. (On a practical level, dynamically setting the is_super column based on 
> role assignment doesn't work as proposed because it can't differentiate 
> between inherited and granted status). 
> 
> What Shailaja is proposing is essentially just some CQL sugar to expose what 
> Roles::hasSuperUserStatus does internally. That doesn't seem entirely 
> unreasonable as it will work with any backing implementation and saves 
> duplicating that logic in any system that consumes this, particularly the 
> sidecar.
> 
> 
>> On 1 Mar 2024, at 12:04, shailajako...@icloud.com wrote:
>> 
>> - 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 a transaction for that, because it can happen 
>> to any column of almost any CQL query. For example, state of 
>> login/options/datacenters etc can also change while we are processing a 
>> query. From my understanding it’s acceptable that user runs the same query 
>> twice and sees difference in the output because of ongoing state changes. 
>> Caller if caching results of a CQL query, may rerun the query periodically 
>> to refresh their cache.
>> 
>> 
>> 
>>> On Mar 1, 2024, at 11:39 AM, shailajako...@icloud.com wrote:
>>> 
>>> 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:30 AM, Štefan Miklošovič 
  wrote:
 
 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 (when a superuser role is 
 revoked and there is none anymore), there would need to be some 
 transaction because as it checks if there are any superuser roles or not 
 to set it to false, somebody else might grant that superuser role to it 
 again so we might end up with having is_superuser set to false while it 
 might still have a superuser role granted.
 
 I am not sure if this is achievable and I am sorry if this was already 
 answered / rejected elsewhere.
 
 On Thu, Feb 29, 2024 at 11:33 AM >>> > wrote:
> 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_superuser column is False for these roles and acquired superuser 
> status is not apparent directly from the columns of this table. member_of 
> column shows immediate parent/grant of a given role. But these grants can 
> result in a huge tree of roles hierarchy and there may be a role anywhere 
> up in the hierarchy which is a superuser.
> 
> cassandra@cqlsh> select * from system_auth.roles;
> 

Re: [DISCUSS] Stream Pipelines on hot paths

[shailajakoppu]

I would like to vote for banning streams in all non-test code. It may not be 
easy for new contributors to distinguish between hot path and non-hot path. So 
would be great if we can simply block them in non-test code and update 
codestyle to detect the usage.


> On Jun 4, 2024, at 6:26 PM, Josh McKenzie  wrote:
> 
> I'm in the "ban in non-test cases, allow in tests" camp. Can sometimes make 
> things more expressive and concise.
> 
> On Mon, Jun 3, 2024, at 12:07 PM, Sam wrote:
>> Added.
>> 
>> Here is the 'after' profile
>> 
>> 
>> 
>> On Sun, 2 Jun 2024 at 20:50, Mick Semb Wever > > wrote:
>>  
>> On profiling a 90% write workload I found 
>> StorageProxy::updateCoordinatorWriteLatencyTableMetric to be a hot-path, 
>> consuming between 15-20% of ModificationStatement::executeWithoutCondition 
>> cycles.
>> 
>> https://github.com/apache/cassandra/pull/3344
>> 
>> 
>> 
>> Ouch.  Ok, I've no idea what constitutes an ok "slow path" now…
>> 
>> Sam, can you also share in the ticket the easy-cass-stress profile you used 
>> please.

Re: [Discuss] CEP-24 Password validation and generation

[shailajakoppu]

Hi Stefan,

Thanks for the CEP, sounds great. Regarding

If we were about to make this even harder to bypass, we may say that password 
can be changed once per day, for example (anytime for a superuser). Since we 
have "created" column which is of type timeuuid, we would check this table and 
see if there was some password already set that day or not and fail the request 
eventually. This is not the part of the initial implementation.

Allowing password change only once a day would be too restrictive and may 
create chaos for users. For example, I am trying to file a tax return on the 
last day of deadline, I forgot the password I had set last year, now changed 
it. Assume I forgot the password I just set either due to an unclear/faulty 
website or due to my bad memory with stress to file tax returns on the last 
day. In that case either I should be able to change the password again or reset 
the password. 

To reuse the same password, I should change the password atleast 5 times, i.e, 
we can allow changing password 4 times a day and after that we can provide a 
reset option which generates a random password. In my experience most of the 
websites/applications allow changing password at least 3 times or 5 times a day 
and locks the account if attempted again. We can still use the reset option to 
unlock the account.

I am hoping applications can tune this restriction using custom guardrails, as 
per their requirement. Am I right?

Thanks,
Shailaja


> On Jun 1, 2024, at 10:42 AM, Miklosovic, Stefan via dev 
>  wrote:
> 
> I feel like this thread deserves an update.
> 
> This CEP was put in a dormant state because there was one quite substantial 
> flaw, that is that if a node is misconfigured in such a way that it would 
> accept weaker passwords than other nodes in a cluster, it would not be safe. 
> The security of such solution would be as safe as the weakiest configuration 
> of a node from a cluster.
> 
> The correct answer to this problem was / is transactional guardrails. I was 
> waiting for TCM to appear in trunk to implement this for year and a half and 
> we are finally there (1) which I am very excited about.
> 
> What transactional guardrails are doing is that each CQL mutation to a 
> respective guardrails virtual table (which is mutable) will commit a 
> transfromation into TCM log. That in turn means that this configuration is 
> propagated to whole cluster and survives restarts etc. That also means that 
> we are configuring any guardrail by one CQL statement for whole cluster in 
> persistent manner which I would say is quite powerful and time / cost saving 
> from techops / devops point of view, especially on a very large scale.
> 
> You can do something like this
> 
> UPDATE system_guardrails.flags SET value = false where name = 
> 'simplestrategy';
> 
> and this will be commited into TCM, everything replayed on restart, same for 
> whole cluster ... you got the idea. Hence, similarly, you can commit 
> configuration for a password validator and it will be same across whole 
> cluster as well.
> 
> This solution received quite positive feedback and it was suggested that we 
> should actually commit into TCM all configuration which is meant to be same 
> for each node.
> 
> I stopped with the introduction of more general "config in TCM" solution as 
> there seems to be entities in this space which are trying to come up with 
> that (that is the vibe I am getting) hence I am currently in kind of a limbo 
> and half-way there.
> 
> Let's see what happens next, I just want to highlight that the next course of 
> action will most probably be the introduction of transactional configuration 
> until this one can finally be integrated with that too. Currently, there is 
> one missing configuration property to be transactional - default_keyspace_rf 
> - because it is used by one of guardrails too. This leads to more general 
> "config in TCM" case which we have not dealt with yet.
> 
> Branch with transactional guardrails is in (2).
> 
> (1) https://issues.apache.org/jira/browse/CASSANDRA-19593
> (2) https://github.com/instaclustr/cassandra/tree/CEP-24-with-generator-tcm
> 
> 
> From: Miklosovic, Stefan 
> Sent: Monday, December 19, 2022 14:24
> To: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
> 
> NetApp Security WARNING: This is an external email. Do not click links or 
> open attachments unless you recognize the sender and know the content is safe.
> 
> 
> 
> 
> One not-so-obvious consequence of the configuration of password validator - 
> since it is based on guardrails - is that if there is a cluster of 50 nodes 
> and we change a configuration (in runtime) in one node, it needs to be done 
> for all remaining 49. We need to be sure that the configuration is same for 
> all nodes because if we do not configure one node the way we want, all it 
> takes to pass the (less secure) validation is to create pas

Re: [Discuss] CEP-24 Password validation and generation

[shailajakoppu]

Agree on your point - password rotation logic is business specific and database 
doesn’t have to worry about that. 


> On Jun 7, 2024, at 6:58 PM, Štefan Miklošovič  
> wrote:
> 
> Hi Shailaja,
> 
> thanks for taking a look at this.
> 
> That was indeed just an example we can change. It was more about showing what 
> might be possible in the future, nothing is set in stone yet, as the last 
> sentence "this is not the part of the initial implementation" explains.
> 
> When it comes to these very specific features you mentioned, I feel like this 
> is very "business specific" and I do not want to "pollute" Cassandra system 
> tables unnecessarily. It was a long time ago since I was writing that CEP and 
> it made sense to me back than to have a table for previous passwords but then 
> I started to reconsider it because I do not know about any database out there 
> which would offer something similar (correct me if I am wrong) plus I start 
> to question its actual benefit for a database user. We are not trying to 
> mimic the behavior of a website after all. More to it, the password rotation 
> itself is quite a topic and there are opinions that password should not be 
> actually rotated at all. Hence I think that it is not the role of Cassandra 
> to define how passwords are going to be rotated, with what frequency etc. 
> Let's just keep it simple and let's just enforce the password strength 
> itself. 
> 
> More to this CEP in general, after I read in the other thread about CEP-42 
> that Dinesh does not consider TCM to be a hard requirement for this CEP and 
> he finds it very useful already, I think I will consolidate what I have and I 
> will remove TCM part of that in order to make it happen sooner. 
> 
> I think I made a mistake by waiting for config in TCM but it was only with 
> good intentions - to provide a comprehensive feature without any compromises. 
> It seems to me that providing a well rounded config in TCM + <> guardrails in 
> TCM was too much for me to handle and it would take way more time than I 
> anticipated and it will be better if this is a more iterative process. I 
> think that based on where I am with the implementation of guardrails in TCM 
> (POC is basically done) it is more or less just a coding exercise to 
> integrate it into general config in TCM once config in TCM is introduced.
> 
> I think I will restructure the current CEP-24 a little bit and I will move 
> more optional features into possible extensions in the future in order to 
> keep the core functionality at the minimum in order to reason about it more 
> easily. I will try to get back to this in the upcoming weeks and I will 
> eventually start a voting thread.
> 
> Regards
> 
> 
> On Fri, Jun 7, 2024 at 6:00 PM  > wrote:
>> Hi Stefan,
>> 
>> Thanks for the CEP, sounds great. Regarding
>> 
>> If we were about to make this even harder to bypass, we may say that 
>> password can be changed once per day, for example (anytime for a superuser). 
>> Since we have "created" column which is of type timeuuid, we would check 
>> this table and see if there was some password already set that day or not 
>> and fail the request eventually. This is not the part of the initial 
>> implementation.
>> 
>> Allowing password change only once a day would be too restrictive and may 
>> create chaos for users. For example, I am trying to file a tax return on the 
>> last day of deadline, I forgot the password I had set last year, now changed 
>> it. Assume I forgot the password I just set either due to an unclear/faulty 
>> website or due to my bad memory with stress to file tax returns on the last 
>> day. In that case either I should be able to change the password again or 
>> reset the password. 
>> 
>> To reuse the same password, I should change the password atleast 5 times, 
>> i.e, we can allow changing password 4 times a day and after that we can 
>> provide a reset option which generates a random password. In my experience 
>> most of the websites/applications allow changing password at least 3 times 
>> or 5 times a day and locks the account if attempted again. We can still use 
>> the reset option to unlock the account.
>> 
>> I am hoping applications can tune this restriction using custom guardrails, 
>> as per their requirement. Am I right?
>> 
>> Thanks,
>> Shailaja
>> 
>> 
>>> On Jun 1, 2024, at 10:42 AM, Miklosovic, Stefan via dev 
>>> mailto:dev@cassandra.apache.org>> wrote:
>>> 
>>> I feel like this thread deserves an update.
>>> 
>>> This CEP was put in a dormant state because there was one quite substantial 
>>> flaw, that is that if a node is misconfigured in such a way that it would 
>>> accept weaker passwords than other nodes in a cluster, it would not be 
>>> safe. The security of such solution would be as safe as the weakiest 
>>> configuration of a node from a cluster.
>>> 
>>> The correct answer to this problem was / is transactional guardrails. I was 
>>> waiting for TC

Re: [VOTE] CEP-24 Password validation / generation

[shailajakoppu]

+1


> On Jun 17, 2024, at 4:24 PM, Dinesh Joshi  wrote:
> 
> +1.
> 
> I have some minor feedback on how the configuration of different character 
> classes works but that can be handled during the patch review.
> 
> On Mon, Jun 17, 2024 at 2:32 AM Štefan Miklošovič  > wrote:
>> Hi everyone,
>> 
>> I would like to start the voting for CEP-24 as all feedback in the 
>> discussion threads seem to be addressed.
>> 
>> Proposal: 
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228494146
>> JIRA under which it will be delivered: 
>> https://issues.apache.org/jira/browse/CASSANDRA-17457
>> Draft implementation: 
>> https://github.com/instaclustr/cassandra/tree/CEP-24-simplified
>> 
>> Discuss threads:
>> 
>> https://lists.apache.org/thread/1hs27lx2pw9lmp7rw499vn0m7vl2bgt1
>> https://lists.apache.org/thread/1hs27lx2pw9lmp7rw499vn0m7vl2bgt1
>> 
>> The reason there are two threads is that I replied to the first one after 
>> that CEP was dormant for a very long time and it just created new thread for 
>> that, most probably an issue with my e-mail client ...
>> 
>> The vote will be open for 72 hours (longer if needed). A vote passes if 
>> there are at least 3 binding +1s and no binding vetoes.
>> 
>> Thanks,
>> 
>> Stefan Miklosovic

Re: [VOTE] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

[shailajakoppu]

+1


> On Jun 27, 2024, at 3:03 PM, Josh McKenzie  wrote:
> 
> +1
> 
> On Thu, Jun 27, 2024, at 12:40 AM, Abhijeet Dubey wrote:
>> +1
>> 
>> On Thu, Jun 27, 2024 at 1:47 AM Francisco Guerrero > > wrote:
>> +1
>> 
>> On 2024/06/21 15:13:31 Venkata Hari Krishna Nukala wrote:
>> > Hi everyone,
>> > 
>> > I would like to start the voting for CEP-40 as all the feedback in the
>> > discussion thread seems to be addressed.
>> > 
>> > Proposal:
>> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-40%3A+Data+Transfer+Using+Cassandra+Sidecar+for+Live+Migrating+Instances
>> > Discussion thread:
>> > https://lists.apache.org/thread/g397668tp0zybf29g8hgbllv7t3j493f
>> > 
>> > As per the CEP process documentation, this vote will be open for 72 hours
>> > (longer if needed).
>> > 
>> > Thanks!
>> > Hari
>> >
>> 
>> 
>> --
>> Abhijeet Dubey
>> Software Engineer @ Apple Inc.
>> IIT Bombay Computer Science & Engineering Class of 2019
>> Contact : +91-9900190105
>> Apple Inc. | IIT Bombay

Re: [VOTE] CEP-42: Constraints Framework

[shailajakoppu]

+1


> On Jul 1, 2024, at 8:34 PM, Doug Rohrer  wrote:
> 
> +1 (nb) - Thanks for all of the suggestions and Bernardo for wrangling the 
> CEP into shape!
> 
> Doug
> 
>> On Jul 1, 2024, at 3:06 PM, Dinesh Joshi  wrote:
>> 
>> +1
>> 
>> On Mon, Jul 1, 2024 at 11:58 AM Ariel Weisberg > > wrote:
>>> Hi,
>>> 
>>> I am +1 on CEP-42 with the latest updates to the CEP to clarify syntax, 
>>> error messages, constraint naming and generated naming, alter/drop, 
>>> describe etc.
>>> 
>>> I think this now tracks very closely to how other SQL databases define 
>>> constraints and the syntax is easily extensible to multi-column and 
>>> multi-table constraints.
>>> 
>>> Ariel
>>> 
>>> On Mon, Jul 1, 2024, at 9:48 AM, Bernardo Botella wrote:
 With all the feedback that came in the discussion thread after the call 
 for votes, I’d like to extend the period another 72 hours starting today.
 
 As before, a vote passes if there are at least 3 binding +1s and no 
 binding vetoes.
 
 Thanks,
 Bernardo Botella
 
> On Jun 24, 2024, at 7:17 AM, Bernardo Botella 
> mailto:conta...@bernardobotella.com>> 
> wrote:
> 
> Hi everyone,
> 
> I would like to start the voting for CEP-42.
> 
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-42%3A+Constraints+Framework
> Discussion: 
> https://lists.apache.org/thread/xc2phmxgsc7t3y9b23079vbflrhyyywj
> 
> The vote will be open for 72 hours. A vote passes if there are at least 3 
> binding +1s and no binding vetoes.
> 
> Thanks,
> Bernardo Botella
>>> 
>