[
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
