In T11433#188778, @chad wrote:

It's not our intention to provide detailed examples for every scenario or operating system, given the tens of thousands of possible examples needed.

It is not any scenario, it is the scenario described in the Phabricator configuration guide (/bin/storage command). Sooner or later any distro will ship with a mysqldump which complains about the way the password is handled.

Can you point to me exactly where we state you should build a cron? https://secure.phabricator.com/book/phabricator/article/configuring_backups/

A better way to think about this is, we only want Phabricator specific things in our documentation. Once an item falls outside of Phabricator, our expectation is you will manage that based on your preference / expertise. Unfortunately with a team of two people, maintaining a greater level of detail in the the documentation is significant and insurmountable.

There are just way better resources on the web for these kinds of things and we don't feel a need to duplicate them.

In T11433#189037, @chad wrote:

Can you point to me exactly where we state you should build a cron? https://secure.phabricator.com/book/phabricator/article/configuring_backups/

Cron is not mentioned explicitly, but no one does manual backups and I would assume that most use cron with the command example you provide.

But the problem is pretty much cron independent: A standard phabricator command displays an ugly warning about insecure password handling.

It is also annoying on the command line or anywhere else this command is executed.

mysqldump is not a phabricator command.

In T11433#189141, @chad wrote:

mysqldump is not a phabricator command.

mysqldump is an internal aspect of the standard phabricator command storage dump.

Oh, yeah that's probably a fair point. @epriestley ?

The Aug 19 2015 reply from James Day in https://bugs.mysql.com/bug.php?id=66546 gives me some hope that MySQL may adjust behavior here. Although that comment is now almost a year old, it responds to a comment from about two and a half years prior, so this may actually be fairly new in MySQL timescales.

For now, I don't plan to implement any of the approaches above: they all increase complexity and I think none meaningfully improve security. With luck, MySQL will provide some remedy for this situation eventually. In the meantime, filtering these messages when integrating bin/storage into some more sophisticated pipeline is trivial.

This document may also be helpful in scripting Phabricator commands:

https://secure.phabricator.com/book/phabricator/article/exit_codes/

I used the subshell redirection trick as mentioned by @epriestley to hide this warning from our cron output as well:

phabricator/bin/storage dump > "$database" 2> >(grep -v "Using a password on the command line interface can be insecure")

Edit: This only works properly in zsh, not in bash.

I'm not sure this works as expected.

phabricator/bin/storage dump > db.backup 2> >(grep -v "SOMETHING")

... shows no output as well. Which means you miss all errors on stderr, which might not be what you want.

It shows no output because there are no warnings. If you replace phabricator/bin/storage dump with a command that does give various formats of warnings on stderr, you see that it works:

$ sh -c 'echo "output1"; echo "error\nwarning\nerror2" 1>&2; echo "output2"' >foo.txt 2> >(grep -v warning)
error
error2
$ cat foo.txt
output1
output2

Ah, I see that it works differently in other shells. The above output was from zsh. In bash, indeed all output is written to the file:

$ sh -c 'echo "output1"; echo "error\nwarning\nerror2" 1>&2; echo "output2"' >foo.txt 2> >(grep -v warning)
$ cat foo.txt 
output1
output2
error
error2

Edited my post above to reflect this.

Yes, the behavior depends on the shell. I was using bash.

That's partly because "\n" isn't a newline in bash:

$ bash -c 'echo "output1"; echo "error\nwarning\nerror2" 1>&2; echo "output2"'
output1
error\nwarning\nerror2
output2

You might need some more sophisticated incantation like this:

epriestley@orbital ~/dev/phabricator $ bash -c 'echo "output1"; echo "error" 1>&2; echo "warning" 1>&2; echo "error2" 1>&2; echo "output2"' >foo.txt 2> >(grep -v warning 1>&2)
error
error2
epriestley@orbital ~/dev/phabricator $ cat foo.txt 
output1
output2

...or try my personal recommendation: don't write anything you care about working correctly in shell script.

The main problem here is that command "./bin/storage dump" exposes password on system process list in clear text. It happens due to way the storage tool calls mysqldump command. In my opinion this is universally applicable to every Linux distribution Phabricator can run on.

(shell) # ps -ef
phd 4691 4690 65 15:02 ? 00:00:47 php /var/opt/phd/phabricator/bin/storage dump --compress --output /mnt/backup/phd-storage-dump.sql.gz
phd 5206 4691 0 15:03 ? 00:00:00 sh -c mysqldump -p'_EXPOSED_PASSWORD_' '--hex-blob' '--single-transaction' '--default-character-set=utf8' '-u' 'root' '-h' 'localhost' '--max-allowed
phd 5207 5206 4 15:03 ? 00:00:02 mysqldump -px xxxxxxxxxxxxx --hex-blob --single-transaction --default-character-set=utf8 -u root -h localhost --max-allowed-packet 1G -- phabricator

As you can see, when the command is executed, mysqldump is displayed twice:

• For "sh -c" process with PID 5206 (parent PID is 4691 - guilty storage dump). This line exposes password in the cleartext.
• For "mysqldump" process with PID 5207 (parent PID is 5206). This line is safe with masked password.

I can live with this because no unpriviledged user has access to the system. But if you have users with shell access who don't need to know PHD database password, then this may be a vulnerability.

MYSQL_PWD can be observed always

I think that’s only the case if you’re root or the user that owns the process, and if an attacker has access to one of those then that's clearly bad news.

Anyway, meanwhile, I notice that MySQL grew a plugin to allow authentication of local users without passwords, so perhaps we can dare to dream of one day looking forward to a utopian passwordless future.