Currently, using MySQL 5.6, Backup and Migrate generates bogus SQL dumps because of this issue: http://bugs.mysql.com/bug.php?id=66546
There's a warning on the stderr and it gets into the dump.
I propose to only append stderr to the dump file when the exit status is not zero.

CommentFileSizeAuthor
#1 backup_migrate-mysql56-comp-2281011-1.patch642 bytesaron novak
backup_migrate_mysql56_warning.patch619 bytesaron novak

Comments

aron novak’s picture

aron novak
Primary language Hungarian
Location Hungary, Budapest
commented
StatusFileSize
new backup_migrate-mysql56-comp-2281011-1.patch642 bytes

a better patch, unlink the file always

morgantocker’s picture

morgantocker commented

The open bug on the MySQL side not withstanding (#66546 is marked as verified), there is actually a small window of time when the password will appear in the operating system's processlist and visible via 'ps'.

I wonder if there is a way to flag drupal's Backup and Migrate functionality as incompatible with those in higher security environments (for example those in ecommerce requiring PCI compliance).

morgantocker’s picture

morgantocker commented

I have filed a bug for mysqldump (separate from 'mysql' cli) here: http://bugs.mysql.com/bug.php?id=72923

yesct’s picture

yesct commented
Issue tags: +Needs upstream bugfix
aron novak’s picture

aron novak
Primary language Hungarian
Location Hungary, Budapest
commented

Well, but do you think that it's really only an upstream bug? Is it a normal behaviour that we save the stderr of the command? I don't think so. Mysqldump does not mix the error with the SQL commands, in Drupal, we do. Would not be better to catch stderr separately, if there's meaningful output on stdout, save it and serve it and show the stderr output to the user? Or something like this. There may be other legitimate cases when mysql says something via stderr but the dump is generated successfully or partially successfully.

morgantocker’s picture

morgantocker commented

@Aron: The upstream bug is really an upstream feature request: provide an easy way for programs such as Drupal to be secure. This is of relevance because the recommended way to secure a deployment is to use mysql_config_editor, but this program will not work non-interactive.

In the interim, I think it is diligent to plan ahead with a solution similar to your proposed patch. The warning is not-bogus though (there is a small risk of the password being captured on the processlist). If there is a way to warn users in high security environments, it makes sense to do so.

aron novak’s picture

aron novak
Primary language Hungarian
Location Hungary, Budapest
commented

Ok, thanks for the explanation, so would you like me to work further on the patch, for example to retrieve the warning and log it for example to dblog, instead of discarding it?

morgantocker’s picture

morgantocker commented

Yes, I like that solution.

couturier’s picture

couturier commented
Status: Needs review » Closed (outdated)

This issue is so old that I am going to go ahead and close it. If this is still a problem with newer versions of Backup and Migrate and MySQL, please re-open under the correct version.

ivnish’s picture

ivnish
he/him
commented
Assigned: aron novak » Unassigned