Guestagent leaves a temporary configuration file in /tmp and this may have some sensitive stuff in it.

[Amrith Kumar]

The issue is here ...

https://github.com/openstack/trove/blob/master/trove/guestagent/datastore/mysql/service.py#L789-L804

The file is created/written/used but not deleted.

[Amrith Kumar (amrith)]

Similar problem exists for other data stores as well.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/112672

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/112672
Committed: https://git.openstack.org/cgit/openstack/trove/commit/?id=cfc729ea6d50655f3426eb053c18b6ae3295a6c3
Submitter: Jenkins
Branch: master

commit cfc729ea6d50655f3426eb053c18b6ae3295a6c3
Author: Amrith Kumar <email address hidden>
Date: Thu Aug 7 15:55:58 2014 -0400

    In some cases, guest agents may leave temporary config files

    The code in these three places manipulates the configuration files. I
    was (admittedly) having more than the acceptable dose of failures in
    execute_with_timeout() and one of them that failed was the move of the
    my.cnf file. And this left a turd in /tmp. The failures I was having
    with execute_with_timeout relate to other tests that were improperly
    mocking/unmocking and some of those problems have now been fixed.

    Found that the same kind of thing can happen in cassandra and
    mongo. Since default umask is 664, this leaves a file with somewhat
    questionable permissions and potentially (at least for MySQL) some
    passwords in /tmp.

    The files will now be deleted.

    Some test cases have been added to exercise the code paths(s) in
    mongo, cassandra and mysql. The tests verify that the files are
    actually deleted by mocking the os.unlink call. setUp and tearDown
    have been updated in each case to make sure that the monkey patching
    is properly reversed.

    Change-Id: I93302fc5b1b18c9dd7116370a945b94d1824c75a
    Closes-Bug: #1354136