Description of problem: debug logs can contain passwords in plaintext Version-Release number of selected component (if applicable): Newton
Eric, I've looked at the LP link. #grep -ir auth_password /var/log/cinder/ returns nothing. The password should be masked from api.log or other log(s)? What command was issued causing the password exposing http response to happen? Once I issue ^ command I should still see "auth_password" but this time followed by *** rather than the password correct? If not how else should I go about verifying this bz?
(In reply to Tzach Shefi from comment #2) This is about the debug logs from cinderclient, not the Cinder API. The case noted in the upstream LP bug is from nova compute during volume attach (initialize connection). The main test would be to set n-cpu to debug and look for the logs like the bug shows. It is also probably worth running some Cinder commands from the CLI with --debug, but I'm not sure of a test case there that matches the LP description.
On A RHOS10 Packstack version: python-cinderclient-1.9.0-4.el7ost.noarch Ran this command: #nova --debug volume-attach 11e99e7b-36bf-4fe8-bc85-0612ea4571a4 6a616f6a-2f4b-4ce8-9173-b8dc50d38ccc auto 2>&1 | tee nova_volume_attach_debug.txt The --debug output didn't show: auth_password or connection_info However Nova compute log did: "connection_info": {"driver_volume_type": "iscsi", "data": {"auth_password": "3ND3dgd9sVGVxsBT", "target_discovered": false, "encrypted": false, "qos_specs": null, "target_iqn": "iqn.2010-10.org.openstack:volume-6a616f6a-2f4b-4ce8-9173-b8dc50d38ccc", "target_portal": "10.35.117.152:3260", "volume_id": "6a616f6a-2f4b-4ce8-9173-b8 Now what am I looking at, a clear text password or it's hash? How do I know for sure this is fixed?
The Nova compute log should mask this password. That needs a separate bug on the nova component to chase. I think this is fixed for cinderclient now so this BZ should be done.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-2948.html