[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526184#comment-17526184 ] Brian Houser edited comment on CASSANDRA-16983 at 4/22/22 3:37 AM: --- I think we agreed to make some minor changes to this (plain_text_auth) in credentials working with the new custom loading system see https://issues.apache.org/jira/browse/CASSANDRA-16456 was (Author: bhouser): I think we agreed to make some minor changes to this (plain_text_auth) in credentials working with the new custom loading system > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Fix For: 4.1 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503862#comment-17503862 ] Brad Schoening edited comment on CASSANDRA-16983 at 3/9/22, 9:47 PM: - [~Bowen Song] yes, I'm providing credentials in CQL_TEST_USER and CQL_TEST_PWD, but test_cqlsh_output in test_no_prompt_or_colors_output is still looking for my cqlshrc and printing out the warning message. Ideally, you'd be able to specify credentials either way, file based or with ENV variables because it can't be done interactively like cqlsh can to request a pwd. was (Author: bschoeni): [~Bowen Song] yes, I'm providing credentials in CQL_TEST_USER and CQL_TEST_PWD, but test_cqlsh_output in test_no_prompt_or_colors_output is still looking for my cqlshrc and printing out the warning message. Ideally, you'd be able to specify credentials either way, file based or with ENV variables because it can't be done interactively like cqlsh can to request a pwd. This seems to happen when a statement is executed with testcall_cqlsh(), not with testrun_cqlsh() > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Fix For: 4.1 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503862#comment-17503862 ] Brad Schoening edited comment on CASSANDRA-16983 at 3/9/22, 9:46 PM: - [~Bowen Song] yes, I'm providing credentials in CQL_TEST_USER and CQL_TEST_PWD, but test_cqlsh_output in test_no_prompt_or_colors_output is still looking for my cqlshrc and printing out the warning message. Ideally, you'd be able to specify credentials either way, file based or with ENV variables because it can't be done interactively like cqlsh can to request a pwd. This seems to happen when a statement is executed with testcall_cqlsh(), not with testrun_cqlsh() was (Author: bschoeni): [~Bowen Song] yes, I'm providing credentials in CQL_TEST_USER and CQL_TEST_PWD, but test_cqlsh_output in test_no_prompt_or_colors_output is still looking for my cqlshrc and printing out the warning message. Ideally, you'd be able to specify credentials either way, file based or with ENV variables because it can't be done interactively like cqlsh can to request a pwd. > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Fix For: 4.1 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503862#comment-17503862 ] Brad Schoening edited comment on CASSANDRA-16983 at 3/9/22, 9:40 PM: - [~Bowen Song] yes, I'm providing credentials in CQL_TEST_USER and CQL_TEST_PWD, but test_cqlsh_output in test_no_prompt_or_colors_output is still looking for my cqlshrc and printing out the warning message. Ideally, you'd be able to specify credentials either way, file based or with ENV variables because it can't be done interactively like cqlsh can to request a pwd. was (Author: bschoeni): [~Bowen Song] yes, I'm providing credentials in CQL_TEST_USER and CQL_TEST_PWD, but test_cqlsh_output is still looking for my cqlshrc and printing out the warning message. Ideally, you'd be able to specify credentials either way, file based or with ENV variables because it can't be done interactively like cqlsh can to request a pwd. > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Fix For: 4.1 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503762#comment-17503762 ] Brad Schoening edited comment on CASSANDRA-16983 at 3/9/22, 6:22 PM: - [~stefan.miklosovic] I'm describing what would happen if you run locally. Say you run cassandra4.0/bin/cqlsh.py with the version from C* 4.0, and then try to run cassandra4.1/bin/cqlsh.py with the version from C* 4.1. You can't run the tests with the same cqlshrc file due to the warning, and that 4.0 won't read the credentials file if you put credentials there. I'm not sure if unittest could ignore the stderr here, but the workaround is that with 4.1 you must use the credentials file, its not optional for a successful test run. [~Bowen Song] I don't know why you had problems with futures, but its not needed anymore, so removing it from requiremens.txt is the right long term fix. I found documentation on the format for the new credentials sparse. Could we update the pylib/README with something about cqlshrc and the new credentials file? Unrelated, but shouldn't the CQLSH version be bumped in C* 4.1 from 6.0.0? was (Author: bschoeni): [~stefan.miklosovic] I'm describing what would happen if you run locally. Say you run cassandra4.0/bin/cqlsh.py with the version from C* 4.0, and then try to run cassandra4.1/bin/cqlsh.py with the version from C* 4.1. You can't run the tests with the same cqlshrc file due to the warning, and that 4.0 won't read the credentials file if you put credentials there. I'm not sure if unittest could ignore the stderr here, but the workaround is that with 4.1 you must [~Bowen Song] I don't know why you had problems with futures, but its not needed anymore, so removing it from requiremens.txt is the right long term fix. I found documentation on the format for the new credentials sparse. Could we update the pylib/README with something about cqlshrc and the new credentials file? Unrelated, but shouldn't the CQLSH version be bumped in C* 4.1 from 6.0.0? > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Fix For: 4.1 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[
https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503262#comment-17503262
]
Brad Schoening edited comment on CASSANDRA-16983 at 3/9/22, 2:55 AM:
-
I wanted to mention that the new warning message emitted when the credential
have not been separated out will cause the python unit tests to fail. I was a
little surprised since the warning was correctly sent to sys.stderr.
FAILED test/test_cqlsh_output.py
This makes the change sort of mandatory for running the tests. Clearly one can
rework their cqlshrc, but I suspect it will not then be compatible across cqlsh
in C* 4.0 and C* 4.1. Cqlshrc will expect the credential in cqlshrc, right?
*E AssertionError: 10 ! output: '\nNotice: Credentials in the cqlshrc
file is deprecated and will be ignored in the future.\nPlease use a credentials
file to specify the username and password.\n\n\n num !\'$#@!~" |
9223372036854775807 | 0xff | True | 1E-14 |
1e+07 | 1e+05 | 2147483647 | 32767 | ∭Ƕ⑮ฑ➳❏\' | 1950-01-01
00:00:00.00+ | 127 | ---- |
newline->
n<- | 9\n\n(1 rows)'*
{*}test/test_cqlsh_output.py{*}:141: AssertionError
was (Author: bschoeni):
I wanted to mention that the new warning message emitted when the credential
have not been separated out will cause the python unit tests to fail. I was a
little surprised since the warning was correctly sent to sys.stderr.
FAILED test/test_cqlsh_output.py
This makes the change sort of mandatory for running the tests. Clearly one can
rework their cqlshrc, but I suspect it will not then be compatible across cqlsh
4.0 and 4.1. Cqlshrc will expect the credential in cqlshrc, right?
*E AssertionError: 10 ! output: '\nNotice: Credentials in the cqlshrc
file is deprecated and will be ignored in the future.\nPlease use a credentials
file to specify the username and password.\n\n\n num !\'$#@!~" |
9223372036854775807 | 0xff | True | 1E-14 |
1e+07 | 1e+05 | 2147483647 | 32767 | ∭Ƕ⑮ฑ➳❏\' | 1950-01-01
00:00:00.00+ | 127 | ---- |
newline->
n<- | 9\n\n(1 rows)'*
{*}test/test_cqlsh_output.py{*}:141: AssertionError
> Separating CQLSH credentials from the cqlshrc file
> --
>
> Key: CASSANDRA-16983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16983
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Bowen Song
>Assignee: Bowen Song
>Priority: Normal
> Labels: lhf
> Fix For: 4.1
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently, the CQLSH tool accepts credentials (username & password) from the
> following 3 places:
> 1. the command line parameter "-p"
> 2. the cqlshrc file
> 3. prompt the user
> This is not ideal.
> Credentials in the command line is a security risk, because it could be see
> by other users on a shared system.
> The cqlshrc file is better, but still not good enough. Because the cqlshrc
> file is a config file, it's often acceptable to have it as a world readable
> file, and share it with other users. It also prevents user from having
> multiple sets of credentials, either for the same Cassandra cluster or
> different clusters.
> To improve the security of CQLSH and make it secure by design, I purpose the
> following changes:
> * Warn the user if a password is giving in the command line, and recommend
> them to use a credential file instead
> * Warn the user if credentials are present in the cqlshrc file and the
> cqlshrc file is not secure (e.g.: world readable or owned by a different user)
> * Deprecate credentials in the cqlshrc, and recommend the user to move them
> to a separate credential file. The aim is to not break anything at the
> moment, but eventually stop accepting credentials from the cqlshrc file.
> * Reject the credentials file if it's not secure, and tell the user how to
> secure it. Optionally, prompt the user for password if it's an interactive
> session. (Think how does OpenSSH handle insecure credential files)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[
https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503262#comment-17503262
]
Brad Schoening edited comment on CASSANDRA-16983 at 3/9/22, 2:41 AM:
-
I wanted to mention that the new warning message emitted when the credential
have not been separated out will cause the python unit tests to fail. I was a
little surprised since the warning was correctly sent to sys.stderr.
FAILED test/test_cqlsh_output.py
This makes the change sort of mandatory for running the tests. Clearly one can
rework their cqlshrc, but I suspect it will not then be compatible across cqlsh
4.0 and 4.1. Cqlshrc will expect the credential in cqlshrc, right?
*E AssertionError: 10 ! output: '\nNotice: Credentials in the cqlshrc
file is deprecated and will be ignored in the future.\nPlease use a credentials
file to specify the username and password.\n\n\n num !\'$#@!~" |
9223372036854775807 | 0xff | True | 1E-14 |
1e+07 | 1e+05 | 2147483647 | 32767 | ∭Ƕ⑮ฑ➳❏\' | 1950-01-01
00:00:00.00+ | 127 | ---- |
newline->
n<- | 9\n\n(1 rows)'*
{*}test/test_cqlsh_output.py{*}:141: AssertionError
was (Author: bschoeni):
I wanted to mention that the new warning message emitted when the credential
have not been separated out will cause the python unit tests to fail. I was a
little surprised since the warning was correctly sent to sys.stderr.
FAILED test/test_cqlsh_output.py
This makes the change sort of mandatory for running the tests.
*E AssertionError: 10 != 6 : output: '\nNotice: Credentials in the
cqlshrc file is deprecated and will be ignored in the future.\nPlease use a
credentials file to specify the username and password.\n\n\n num | asciicol |
bigintcol | blobcol | booleancol | decimalcol |
doublecol | floatcol | intcol | smallintcol | textcol | timestampcol
| tinyintcol | uuidcol | varcharcol
|
varintcol\n-++-+--+++---+--++-+-+-++--+---+---\n
1 | __!\'$#@!~" | 9223372036854775807 | 0xff | True |
1E-14 | 1e+07 | 1e+05 | 2147483647 | 32767 | ∭Ƕ⑮ฑ➳❏\' |
1950-01-01 00:00:00.00+ | 127 |
---- | newline->\\n<- | 9\n\n(1 rows)'*
*test/test_cqlsh_output.py*:141: AssertionError
> Separating CQLSH credentials from the cqlshrc file
> --
>
> Key: CASSANDRA-16983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16983
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Bowen Song
>Assignee: Bowen Song
>Priority: Normal
> Labels: lhf
> Fix For: 4.1
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently, the CQLSH tool accepts credentials (username & password) from the
> following 3 places:
> 1. the command line parameter "-p"
> 2. the cqlshrc file
> 3. prompt the user
> This is not ideal.
> Credentials in the command line is a security risk, because it could be see
> by other users on a shared system.
> The cqlshrc file is better, but still not good enough. Because the cqlshrc
> file is a config file, it's often acceptable to have it as a world readable
> file, and share it with other users. It also prevents user from having
> multiple sets of credentials, either for the same Cassandra cluster or
> different clusters.
> To improve the security of CQLSH and make it secure by design, I purpose the
> following changes:
> * Warn the user if a password is giving in the command line, and recommend
> them to use a credential file instead
> * Warn the user if credentials are present in the cqlshrc file and the
> cqlshrc file is not secure (e.g.: world readable or owned by a different user)
> * Deprecate credentials in the cqlshrc, and recommend the user to move them
> to a separate credential file. The aim is to not break anything at the
> moment, but eventually stop accepting credentials from the cqlshrc file.
> * Reject the credentials file if it's not secure, and tell the user how to
> secure it. Optionally, prompt the user for password if it's an interactive
> session. (Think how does OpenSSH handle insecure credential files)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.ap
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17426127#comment-17426127 ] Stefan Miklosovic edited comment on CASSANDRA-16983 at 10/8/21, 11:53 AM: -- tested manually locally, works fine. I triggered the build here with Bowen's dtest: https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1194/ On successful build I am +1, I would like to get the second +1 from another committer. was (Author: stefan.miklosovic): tested manually locally, works fine. I triggered the build here with Bowen's dtest: https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1193/ On successful build I am +1, I would like to get the second +1 from another committer. > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421774#comment-17421774 ] Bowen Song edited comment on CASSANDRA-16983 at 9/28/21, 8:33 PM: -- I could describe it in the code, but not making the option visible to the end user. This way, the option won't show up in the `cqlsh --help` output or the [HTML document|https://cassandra.apache.org/doc/latest/cassandra/tools/cqlsh.html], but if anyone reads (or searches it in) the source code of cqlsh.py, the option will be clearly documented. was (Author: bowen song): I could describe it in the code, but not making the option visible to the end user. This way, the option won't show up in the `cqlsh --help` output or the [HTML document|https://cassandra.apache.org/doc/latest/cassandra/tools/cqlsh.html], but if anyone read (or search it in) the source code of cqlsh.py, the option will be clearly documented. > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420875#comment-17420875 ] Bowen Song edited comment on CASSANDRA-16983 at 9/27/21, 4:28 PM: -- Okay, I need some opinions on the following issue. The 'cqlsh_tests' in dtests doesn't like the newly added insecure password in command line warning message, and many tests will fail if the warning text is added without any other actions taken. I can think of 3 different solutions: 1. Add a new undocumented hidden option to 'cqlsh.py' to skip the warning message when '\-p password' is used. For example "--insecure-password-without-warning". Then in the dtests, add this parameter to the command line if the Cassandra version is >= a specific value, such as '4.1'. 2. Add a new undocumented environment variable to 'cqlsh.py' to skip the warning message. For example "CQLSH_INSECURE_PASSWORD_WITHOUT_WARNING=1". In dtests, the environment variable can be set regardless of the version, as the old version cqlsh will ignore it automatically. 3. Change the dtests to expect the warning message if the Cassandra version is >= a specific value. I would like to hear your opinions on the above, what do you think is the best approach? was (Author: bowen song): Okay, I need some opinions on the following issue. The 'cqlsh_tests' in dtests doesn't like the newly added insecure password in command line warning message, and many tests will fail if the warning text is added without any other actions taken. I can think of 3 different solutions: 1. Add a new undocumented hidden option to 'cqlsh.py' to skip the warning message when '-p password' is used. For example "--insecure-password-without-warning". Then in the dtests, add this parameter to the command line if the Cassandra version is >= a specific value, such as '4.1'. 2. Add a new undocumented environment variable to 'cqlsh.py' to skip the warning message. For example "CQLSH_INSECURE_PASSWORD_WITHOUT_WARNING=1". In dtests, the environment variable can be set regardless of the version, as the old version cqlsh will ignore it automatically. 3. Change the dtests to expect the warning message if the Cassandra version is >= a specific value. I would like to hear your opinions on the above, what do you think is the best approach? > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420875#comment-17420875 ] Bowen Song edited comment on CASSANDRA-16983 at 9/27/21, 4:28 PM: -- Okay, I need some opinions on the following issue. The 'cqlsh_tests' in dtests doesn't like the newly added insecure password in command line warning message, and many tests will fail if the warning text is added without any other actions taken. I can think of 3 different solutions: 1. Add a new undocumented hidden option to 'cqlsh.py' to skip the warning message when '-p password' is used. For example "--insecure-password-without-warning". Then in the dtests, add this parameter to the command line if the Cassandra version is >= a specific value, such as '4.1'. 2. Add a new undocumented environment variable to 'cqlsh.py' to skip the warning message. For example "CQLSH_INSECURE_PASSWORD_WITHOUT_WARNING=1". In dtests, the environment variable can be set regardless of the version, as the old version cqlsh will ignore it automatically. 3. Change the dtests to expect the warning message if the Cassandra version is >= a specific value. I would like to hear your opinions on the above, what do you think is the best approach? was (Author: bowen song): Okay, I need some opinions on the following issue. The 'cqlsh_tests' in dtests doesn't like the newly added insecure password in command line warning message, and many tests will fail if the warning text is added without any other actions taken. I can think of 3 different solutions: 1. Add a new undocumented hidden option to 'cqlsh.py' to skip the warning message when '\-p password' is used. For example "\-\-insecure-password-without-warning". Then in the dtests, add this parameter to the command line if the Cassandra version is >= a specific value, such as '4.1'. 2. Add a new undocumented environment variable to 'cqlsh.py' to skip the warning message. For example "CQLSH_INSECURE_PASSWORD=1". In dtests, the environment variable can be set regardless of the version, as the old version cqlsh will ignore it automatically. 3. Change the dtests to expect the warning message if the Cassandra version is >= a specific value. I would like to hear your opinions on the above, what do you think is the best approach? > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420875#comment-17420875 ] Bowen Song edited comment on CASSANDRA-16983 at 9/27/21, 4:27 PM: -- Okay, I need some opinions on the following issue. The 'cqlsh_tests' in dtests doesn't like the newly added insecure password in command line warning message, and many tests will fail if the warning text is added without any other actions taken. I can think of 3 different solutions: 1. Add a new undocumented hidden option to 'cqlsh.py' to skip the warning message when '\-p password' is used. For example "\-\-insecure-password-without-warning". Then in the dtests, add this parameter to the command line if the Cassandra version is >= a specific value, such as '4.1'. 2. Add a new undocumented environment variable to 'cqlsh.py' to skip the warning message. For example "CQLSH_INSECURE_PASSWORD=1". In dtests, the environment variable can be set regardless of the version, as the old version cqlsh will ignore it automatically. 3. Change the dtests to expect the warning message if the Cassandra version is >= a specific value. I would like to hear your opinions on the above, what do you think is the best approach? was (Author: bowen song): Okay, I need some opinions on the following issue. The 'cqlsh_tests' in dtests doesn't like the newly added insecure password in command line warning message, and many tests will fail if the warning text is added without any other actions taken. I can think of 3 different solutions: 1. Add a new undocumented hidden option to 'cqlsh.py' to skip the warning message when '-p password' is used. For example "--insecure-password-without-warning". Then in the dtests, add this parameter to the command line if the Cassandra version is >= a specific value, such as '4.1'. 2. Add a new undocumented environment variable to 'cqlsh.py' to skip the warning message. For example "CQLSH_INSECURE_PASSWORD=1". In dtests, the environment variable can be set regardless of the version, as the old version cqlsh will ignore it automatically. 3. Change the dtests to expect the warning message if the Cassandra version is >= a specific value. I would like to hear your opinions on the above, what do you think is the best approach? > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420875#comment-17420875 ] Bowen Song edited comment on CASSANDRA-16983 at 9/27/21, 4:26 PM: -- Okay, I need some opinions on the following issue. The 'cqlsh_tests' in dtests doesn't like the newly added insecure password in command line warning message, and many tests will fail if the warning text is added without any other actions taken. I can think of 3 different solutions: 1. Add a new undocumented hidden option to 'cqlsh.py' to skip the warning message when '-p password' is used. For example "--insecure-password-without-warning". Then in the dtests, add this parameter to the command line if the Cassandra version is >= a specific value, such as '4.1'. 2. Add a new undocumented environment variable to 'cqlsh.py' to skip the warning message. For example "CQLSH_INSECURE_PASSWORD=1". In dtests, the environment variable can be set regardless of the version, as the old version cqlsh will ignore it automatically. 3. Change the dtests to expect the warning message if the Cassandra version is >= a specific value. I would like to hear your opinions on the above, what do you think is the best approach? was (Author: bowen song): Okay, I need some opinions on the following issue. The 'cqlsh_tests' in dtests doesn't like the newly added insecure password in command line warning message, and many tests will fail if the warning text is added without any other actions taken. I can think of 3 different solutions: 1. Add a new undocumented hidden option to 'cqlsh.py' to skip the warning message when '-p password' is used. For example "--insecure-password-without-warning". Then in the dtests, add this parameter to the command line if the Cassandra version is >= a specific value, such as '4.1'. 2. Add a new undocumented environment variable to 'cqlsh.py' to skip the warning message. For example "CQLSH_INSECURE_PASSWORD=1". In dtests, the environment variable can be set regardless of the version, as the old version cqlsh will ignore it automatically. 3. Change the dtests to expect the warning message if the Cassandra version is >= a specific value. I would like to hear your opinions on the above, what do you think is the best approach? > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[
https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420723#comment-17420723
]
Bowen Song edited comment on CASSANDRA-16983 at 9/27/21, 1:15 PM:
--
I have installed `ant` and built the JAR files:
{noformat}
$ ant realclean && ant jar
..
_build-test:
[javac] Compiling 1034 source files to
/home/user/cassandra_fork/build/test/classes
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[copy] Copying 27 files to /home/user/cassandra_fork/build/test/classes
jar:
[mkdir] Created dir: /home/user/cassandra_fork/build/classes/stress/META-INF
[mkdir] Created dir: /home/user/cassandra_fork/build/tools/lib
[jar] Building jar: /home/user/cassandra_fork/build/tools/lib/stress.jar
[mkdir] Created dir:
/home/user/cassandra_fork/build/classes/fqltool/META-INF
[jar] Building jar: /home/user/cassandra_fork/build/tools/lib/fqltool.jar
BUILD SUCCESSFUL
Total time: 50 seconds
{noformat}
However, the dtests are still failing. Any idea how to troubleshoot it?
BTW, I didn't wait for it to complete this time, because the tests are all
failing anyway...
{noformat}
auditlog_test.py F
[ 0%]
auth_join_ring_false_test.py
[ 0%]
auth_test.py
FFsssFEEE
[ 8%]
batch_test.py FFsss
[ 10%]
{noformat}
EDIT: never mind, I've figured it out. I have to set the JAVA_HOME env var,
even though `java` command is in $PATH, the tests won't use it unless JAVA_HOME
is set.
was (Author: bowen song):
I have installed `ant` and built the JAR files:
{noformat}
$ ant realclean && ant jar
..
_build-test:
[javac] Compiling 1034 source files to
/home/user/cassandra_fork/build/test/classes
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[copy] Copying 27 files to /home/user/cassandra_fork/build/test/classes
jar:
[mkdir] Created dir: /home/user/cassandra_fork/build/classes/stress/META-INF
[mkdir] Created dir: /home/user/cassandra_fork/build/tools/lib
[jar] Building jar: /home/user/cassandra_fork/build/tools/lib/stress.jar
[mkdir] Created dir:
/home/user/cassandra_fork/build/classes/fqltool/META-INF
[jar] Building jar: /home/user/cassandra_fork/build/tools/lib/fqltool.jar
BUILD SUCCESSFUL
Total time: 50 seconds
{noformat}
However, the dtests are still failing. Any idea how to troubleshoot it?
BTW, I didn't wait for it to complete this time, because the tests are all
failing anyway...
{noformat}
auditlog_test.py F
[ 0%]
auth_join_ring_false_test.py
[ 0%]
auth_test.py
FFsssFEEE
[ 8%]
batch_test.py FFsss
[ 10%]
{noformat}
> Separating CQLSH credentials from the cqlshrc file
> --
>
> Key: CASSANDRA-16983
> URL: https://issues.apache.org/jira/browse/CAS
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420680#comment-17420680 ] Stefan Miklosovic edited comment on CASSANDRA-16983 at 9/27/21, 11:49 AM: -- Could you done a test which is dealing with file permissions only? Lets just verify all "sudo-needed" tests manually for now. At least something. Yes you need Ant and yes you need Java development kit, you need to produce Cassandra JAR which is then started by CCM Python library. Dtests build the Cassandra JAR first before running tests against that. was (Author: stefan.miklosovic): Could you done a test which is dealing with file permissions only? Lets just verify all "sudo-needed" tests manually for now. At least something. Yes you need Ant and yes you need Java development kit, you need to produce Cassandra JAR which is then started by CCM Python library. Dtests are build the Cassandra JAR first before running tests against that. > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[
https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420627#comment-17420627
]
Bowen Song edited comment on CASSANDRA-16983 at 9/27/21, 9:49 AM:
--
Hi [~stefan.miklosovic], I've just tried that, and I don't think it's working
either.
I have followed the README and installed the native dependencies and Python
dependencies, and the command I used to run the tests is "pytest
--cassandra-dir=$HOME/cassandra_fork". I first tried to use `\~` as the
document suggested, but that did not work for me, the test failed with "E
FileNotFoundError: [Errno 2] No such file or directory:
'\~/cassandra_fork/build.xml'" immediately. The test runs after replacing `\~`
with `$HOME`, but most of them are failing. The output at the end is "724
failed, 99 passed, 240 skipped, 4088 deselected, 2 xfailed, 162 error in 725.86
seconds". I can only see hundreds lines of these errors repeating:
{noformat}
[, ,
,
]
test_thread_count_repair failed and was not selected for rerun.
'JAVA_HOME'
[, ,
,
]
test_multiple_concurrent_repairs failed and was not selected for rerun.
'JAVA_HOME'
[, ,
,
]
test_wide_row_repair failed and was not selected for rerun.
'JAVA_HOME'
[, ,
,
]
test_dead_sync_initiator failed and was not selected for rerun.
list index out of range
[, , ,
]
test_dead_sync_participant failed and was not selected for rerun.
list index out of range
[, , ,
]
test_failure_during_validation failed and was not selected for rerun.
list index out of range
[, , ,
]
{noformat}
Any tips on how to run this correctly?
was (Author: bowen song):
Hi [~stefan.miklosovic], I've just tried that, and I don't think it's working
either.
I have followed the README and installed the native dependencies and Python
dependencies, and the command I used to run the tests is "pytest
--cassandra-dir=$HOME/cassandra_fork". I first tried to use `~` as the document
suggested, but that did not work for me, the test failed with "E
FileNotFoundError: [Errno 2] No such file or directory:
'~/cassandra_fork/build.xml'" immediately. The test runs after replacing `~`
with `$HOME`, but most of them are failing. The output at the end is "724
failed, 99 passed, 240 skipped, 4088 deselected, 2 xfailed, 162 error in 725.86
seconds". I can only see hundreds lines of these errors repeating:
{noformat}
[, ,
,
]
test_thread_count_repair failed and was not selected for rerun.
'JAVA_HOME'
[, ,
,
]
test_multiple_concurrent_repairs failed and was not selected for rerun.
'JAVA_HOME'
[, ,
,
]
test_wide_row_repair failed and was not selected for rerun.
'JAVA_HOME'
[, ,
,
]
test_dead_sync_initiator failed and was not selected for rerun.
list index out of range
[, , ,
]
test_dead_sync_participant failed and was not selected for rerun.
list index out of range
[, , ,
]
test_failure_during_validation failed and was not selected for rerun.
list index out of range
[, , ,
]
{noformat}
Any tips on how to run this correctly?
> Separating CQLSH credentials from the cqlshrc file
> --
>
> Key: CASSANDRA-16983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16983
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Bowen Song
>Assignee: Bowen Song
>Priority: Normal
> Labels: lhf
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, the CQLSH tool accepts credentials (username & password) from the
> following 3 places:
> 1. the command line parameter "-p"
> 2. the cqlshrc file
> 3. prompt the user
> This is not ideal.
> Credentials in the command line is a security risk, because it could be see
> by other users on a shared system.
> The cqlshrc file is better, but still not good enough. Because the cqlshrc
> file is a config file, it's often acceptable to have it as a world readable
> file, and share it with other users. It also prevents user from having
> multiple sets of credentials, either for the same Cassandra cluster or
> different clusters.
> To improve the security of CQLSH and make it secure by design, I purpose the
> following changes:
> * Warn the user if a password is giving in the command line, and recommend
> them to use a credential file instead
> * Warn the user if credentials are present in the cqlshrc file and the
> cqlshrc file is not secure (e.g.: world readable or owned by a different user)
> * Deprecate credentials in the cqlshrc, and r
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420410#comment-17420410 ] Bowen Song edited comment on CASSANDRA-16983 at 9/26/21, 11:40 PM: --- Hi [~stefan.miklosovic], I can read and understand Java code, and can write bad (possibly very bad) Java code too. Also, I don't have a Java development environment, so I'll have no way to compile and run the Java tests. If I wrote some Java tests, I'll need to commit it as it is and hoping for the best. I'm not sure that's acceptable? I can write much better Python tests, but I'm having trouble to understand how is the Python test run. I tried to run "nosetests" directly, but tests are failing with all sorts of errors. I can see the unittests are more like integrations tests, many of them depend on a running Cassandra cluster. Can anyone please point me to a document about it, a script that invokes the test or a correct (list of?) command to run the tests? And, one more thing, is the test run as root on the CI system? Because in order to test the change, the test will need to have root access. Specifically, it will need access to "chown", "useradd" and "userdel" commands, which are not available to non-root user. I'm afraid the `fakeroot` command won't cut it, because I will need to be able to switch between users (su/sudo/etc.) in order to test some of the code. was (Author: bowen song): Hi [~stefan.miklosovic], I can read and understand Java code, and can write bad (possibly very bad) Java code too. Also, I don't have a Java development environment, so I'll have no way to compile and run the Java tests. If I wrote some Java tests, I'll need to commit it as it is and hoping for the best. I'm not sure that's acceptable? I can write much better Python tests, but I'm having trouble to understand how is the Python test run. I tried to run "nosetests" directly, but tests are failing with all sorts of errors. I can see the unittests are more like integrations tests, many of them depend on a running Cassandra cluster. Can anyone please point me to a document about it, a script that invokes the test or a correct (list of?) command to run the tests? > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420398#comment-17420398 ] Stefan Miklosovic edited comment on CASSANDRA-16983 at 9/26/21, 9:52 PM: - Hi [~Bowen Song], great patch! The only thing I am kind of lacking are some tests. I think this can be tested via CQLSH invoked from Java as a tool. Check the package test/unit/org/apache/cassandra/tools/cqlsh/CqlshTest. There is a bunch of stuff in ToolRunner related to cqlsh and it is imo just a matter of putting all the bits together to test what you just implemented. EDIT: you might also implement this in cassandra-dtest (repo under apache org in gh) which is written in Python if that is your expertise but I would like to see this in Java first and if not possible or too hard for you, I guess some tests in cassandra-dtest might do it too. was (Author: stefan.miklosovic): Hi [~Bowen Song], great patch! The only thing I am kind of lacking are some tests. I think this can be tested via CQLSH invoked from Java as a tool. Check the package test/unit/org/apache/cassandra/tools/cqlsh/CqlshTest. There is a bunch of stuff in ToolRunner related to cqlsh and it is imo just a matter of putting all the bits together to test what you just implemented. > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
