When you connect to a MySQL server, you should use a password. The password is not transmitted in clear text over the connection. Password handling during the client connection sequence was upgraded in MySQL 4.1.1 to be very secure. If you are still using pre-4.1.1-style passwords, the encryption algorithm is not as strong as the newer algorithm. With some effort, a clever attacker who can sniff the traffic between the client and the server can crack the password. (See Section 18.104.22.168, "Password Hashing in MySQL", for a discussion of the different password handling methods.)
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.9, "Using SSL for Secure 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
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 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.3.5, "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,
prevent this, mysqld refuses to run as
root unless that is specified explicitly using the
mysqld can (and should) be run as an ordinary,
unprivileged user instead. You can create a separate Unix account named
mysql to make everything even more secure. Use this account only for
administering MySQL. To start mysqld as a different Unix user, add a
user option that specifies the user name in the
[mysqld] group of the
file where you specify server options. For example:
This causes the server to start as the designated user whether you start it manually or by using mysqld_safe or mysql.server. For more details, see Section 6.1.5, "How to Run MySQL as a Normal User".
Running mysqld as a Unix user other than
root does not mean that you need to change the
root user name in the
user table. User names for MySQL accounts have nothing to do with user names for Unix
Do not grant the
FILE privilege to nonadministrative users. Any user that has this
privilege can write a file anywhere in the file system with the privileges of the mysqld daemon. This includes the server's data
directory containing the files that implement the privilege tables. To make
FILE-privilege operations a bit safer, files generated with
SELECT ... INTO OUTFILE do not overwrite existing files and are
writable by everyone.
may also be used to read any file that is world-readable or accessible to the Unix user that the
server runs as. With this privilege, you can read any file into a database table. This could be
abused, for example, by using
DATA to load
/etc/passwd into a table, which then can
be displayed with
Do not grant the
SUPER privilege to nonadministrative users. The output of mysqladmin processlist and
SHOW PROCESSLIST shows the text of any statements currently being
executed, so any user who is permitted to see the server process list might be able to see statements
issued by other users such as
UPDATE user SET
can be used to terminate client connections, change server operation by changing the value of system
variables, and control replication servers.
Do not permit the use of symlinks to tables. (This capability can be disabled with
option.) This is especially important if you run mysqld as
anyone that has write access to the server's data directory then could delete any file in the system!
See Section 22.214.171.124.2, "Using
Symbolic Links for
MyISAM Tables on Unix".
Stored programs and views should be written using the security guidelines discussed in Section 18.6, "Access Control for Stored Programs and Views".
If you do not trust your DNS, you should use IP addresses rather than host names in the grant tables. In any case, you should be very careful about creating grant table entries using host name values that contain wildcards.
If you want to restrict the number of connections permitted to a single account,
you can do so by setting the
max_user_connections variable in mysqld. The
GRANT statement also supports resource control options for limiting
the extent of server use permitted to an account. See Section
If the plugin directory is writable by the server, it may be possible for a user to
write executable code to a file in the directory using
SELECT ... INTO DUMPFILE. This can be prevented by making
read only to the server or by setting
--secure-file-priv to a directory where
SELECT writes can be made safely.