Shameless promotion: please check out oak-secutiry-audit, a utility which audits your MySQL installation against many security holes and weaknesses, covering empty passwords, duplicate passwords, permissive grants, weak configuration etc.

While Linux security is often considered good, an astonishing weakness is “ps aux”, where *every* user can see *every* process running. Therefore, even user “games” can see that user root is running “mysql -pmypassword”.
I find this a much higher risk than putting the MySQL’s root password in file, where a user need to gain access to machine’s “root”.

Still, linux security is by far higher than MySQL security (I have no proof for this, just the common understanding). If you chmod 600 /root/.my.cnf, may be move it to /root/surprise/unexpected.filename (who says it’s to be called my.cnf?), you add some more confusion (though still easily hacked by the experienced).

Obviously, for specific cronjob tasks, just create the required users with limited privileges, never with GRANT OPTION. However, I find that for many tasks, the abused SUPER privilege is required, which allows for nasty stuff like KILL etc.).

But yes, ~/.bash_history and ~/.mysql_history is indeed another thing to bear in mind for the security conscious person!

In your example the password also ends up in the bash history file :p

I’ve never liked having to enter passwords to a service I should already have permissions to. It encourages people to use things that they can remember easily, which generally means that the passwords are weak, or repeated elsewhere.

What’s more insecure is passing password as an argument to MySQL, like you’ve written (-p[password]), since that can really be seen by anyone.