[
https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421023#comment-17421023
]
Bowen Song commented on CASSANDRA-16983:
----------------------------------------
[~brandon.williams] I'm a bit worried that doing a substring match may miss
cases where there's a real error following the warning message. I don't like
the exact match idea either, because it basically locks in the message itself.
I can think of a few solutions to avoid locking down the message text or
ignoring additional errors / warnings in the test:
1. Make the warning text a module level (pretty much a global) variable in
cqlsh, then import the variable from cqlsh in the unittest. The less ideal part
is cqlsh.py has tons of code gets executed at import time, and they are not
exactly what I would say 'fast'.
2. Put the warning text in another .py file, and import it from both cqlsh.py
and the unittest. I think the best place is in cqlshlib, but I'm unsure
`util.py` is the best file for that. It's a bit messy because the message
really isn't reusable other than being used by the test.
3. Do a substring match and an additional check on the number of lines in the
hope of any other warning or error will add at least one additional line to the
stderr. This way the content is flexible but the number of lines is locked down
by the unittest. This is a compromise between doing too much and too little.
TBH, I'd rather add an undocumented hidden option and be done with it. Regular
user will never find it out, and advanced users can use that option to silence
the warning if they chose to do so. This way, the unittest would be a lot
clearer. The option itself can also be tested by the unittest using a substring
match, without worrying about additional errors after it, because the same test
without the hidden option will still catch that error.
Let me know your thoughts on this.
> 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: [email protected]
For additional commands, e-mail: [email protected]
