An implication of password rewriting is that statements that cannot be parsed (due, for example, to syntax errors) are not written to the general query log because they cannot be known to be password free. Use cases that require logging of all statements including those with errors should use the --log-raw  option, bearing in mind that this also bypasses password rewriting. 

Password rewriting occurs only when plain text passwords are expected. For statements with syntax that expect a password hash value, no rewriting occurs. If a plain text password is supplied erroneously for such syntax, the password is logged as given, without rewriting. 

To guard log files against unwarranted exposure, locate them in a directory that restricts access to the server and the database administrator. If the server logs to tables in the mysql  database, grant access to those tables only to the database administrator. 

Replicas store the password for the replication source server in their connection metadata repository, which by default is a table in the mysql  database named slave_master_info . The use of a file in the data directory for the connection metadata repository is now deprecated, but still possible (see Section 17.2.4, “Relay Log and Replication Metadata Repositories” ). Ensure that the connection metadata repository can be accessed only by the database administrator. An alternative to storing the password in the connection metadata repository is to use the START REPLICA | SLAVE  or START GROUP_REPLICATION  statement to specify credentials for connecting to the source. 

Use a restricted access mode to protect database backups that include log tables or log files containing passwords. 

## 6.1.3 Making MySQL Secure Against Attackers 

When you connect to a MySQL server, you should use a password. The password is not transmitted as cleartext over the connection. 

All other information is transferred as text, and can be read by anyone who is able to watch the connection. If the connection between the client and the server goes through an untrusted network, and you are concerned about this, you can use the compressed protocol to make traffic much more difficult to decipher. You can also use MySQL’s internal SSL support to make the connection even more secure. See Section 6.3, “Using Encrypted Connections” . Alternatively, use SSH to get an encrypted TCP/IP connection between a MySQL server and a MySQL client. You can find an Open Source SSH client at http://www.openssh.org/, and a comparison of both Open Source and Commercial SSH clients at http:// en.wikipedia.org/wiki/Comparison_of_SSH_clients. 

To make a MySQL system secure, you should strongly consider the following suggestions: 

•Require all MySQL accounts to have a password. A client program does not necessarily know the identity of the person running it. It is common for client/server applications that the user can specify any user name to the client program. For example, anyone can use the mysql  program to connect as any other person simply by invoking it as mysql -u other_user db_name  if other_user  has no password. If all accounts have a password, connecting using another user’s account becomes much more difficult. 

For a discussion of methods for setting passwords, see Section 6.2.14, “Assigning Account Passwords” . 

•Make sure that the only Unix user account with read or write privileges in the database directories is the account that is used for running mysqld . 

•Never run the MySQL server as the Unix root  user. This is extremely dangerous, because any user with the FILE  privilege is able to cause the server to create files as root  (for example, ~root/.bashrc ). To prevent this, mysqld  refuses to run as root  unless that is specified explicitly using the --user=root  option. 

