Secure MySQL config files and credentials

The fix

sudo chown root:mysql /etc/mysql/my.cnf
sudo chmod 640 /etc/mysql/my.cnf
sudo chmod 640 /etc/mysql/mysql.conf.d/*.cnf

chmod 600 ~/.my.cnf
sudo chmod 750 /var/lib/mysql

Substitute mariadb.conf.d if that’s what you’re running.

Why it matters

Config files hold credentials in cleartext. ~/.my.cnf exists precisely so you can put a password in it, and my.cnf frequently grows a [client] section for the same reason. A world-readable one means every local account — every service user, every deployment agent, anything that gets a shell through an unrelated bug — can read the database password.

This is low because it needs local access first. It is on the list because it quietly undoes the work of every other page: a perfect grant model protected by a 644 file with the password in it isn’t protecting much.

Never put a password on the command line

This is the more interesting half, and it catches people who’d never chmod a config file wrong:

mysql -u app -phunter2 appdb          # don't

Command lines are world-readable on Linux. Any user on the box can run ps aux — or read /proc/<pid>/cmdline — and see it while the process runs. MySQL warns about this (“Using a password on the command line interface can be insecure”), and the warning is routinely suppressed rather than heeded.

It’s worse in scripts, because the password then lives in the shell history, in CI logs, and in any process listing captured by monitoring.

Use login-path instead

MySQL ships the right answer, and it’s underused. mysql_config_editor writes an obfuscated credential file that the client reads automatically:

mysql_config_editor set --login-path=prod --host=10.0.1.5 --user=app --password
# prompts for the password, stores it in ~/.mylogin.cnf

mysql --login-path=prod appdb
mysqldump --login-path=prod appdb > backup.sql

Be precise about what this does: ~/.mylogin.cnf is obfuscated, not encrypted. Anyone who can read the file can recover the password — mysql_config_editor print --all does it for you. It is not a secret store.

What it genuinely buys you is that the password is never in a command line, never in shell history, and never in a CI log. Those are the leaks that actually happen. File permissions still do the real work, and mysql_config_editor sets the file to 600 itself.

MariaDB does not ship mysql_config_editor. Use a 600 option file with a [client] section and --defaults-file, which achieves the same thing minus the obfuscation.

Verify it worked

Check permissions:

ls -l /etc/mysql/my.cnf /etc/mysql/*/*.cnf ~/.my.cnf ~/.mylogin.cnf 2>/dev/null
ls -ld /var/lib/mysql

Expect no world bit anywhere. Find any world-readable file that mentions a password:

sudo find /etc/mysql -type f -perm -o=r -exec grep -lI 'password' {} \; 2>/dev/null

Expect no output. Any file listed here leaks a credential to every account on the host.

Prove it as an unprivileged user:

sudo -u nobody cat /etc/mysql/my.cnf

Expect permission denied.

Then check nobody is passing passwords on command lines right now:

ps aux | grep -iE 'mysql.*-p[^ ]' | grep -v grep

Any output is a password currently visible to every user on the box. Also grep your automation:

grep -rIn -- '-p[^ ]' /etc/cron.d /etc/cron.daily 2>/dev/null | grep -i mysql

Before you apply this

Getting the ownership wrong stops MySQL from starting, and the error is a permissions complaint in the journal rather than anything that names the file.

The rule: the file must remain readable by the user MySQL runs as. root:mysql with 640 works because mysqld is in the mysql group. root:root with 640 does not — mysqld cannot read its own config.

Check before restarting:

sudo -u mysql test -r /etc/mysql/my.cnf && echo readable || echo BROKEN

/var/lib/mysql needs write access for the mysql user, not just read. 750 owned by mysql:mysql is correct. Tightening it to 700 is fine; 640 on the directory breaks the server, because a directory needs the execute bit to be traversed at all.

One caution about ~/.my.cnf: fixing its permissions is safe, but deleting it breaks whatever was relying on it — often a backup cron job that has been working silently for years and has no other credential source. Check before you tidy:

sudo grep -rIl 'my.cnf\|login-path' /etc/cron* /etc/systemd/system 2>/dev/null

Related

• Grant least privilege — limits what a leaked credential can do.
• Authentication plugins — unix_socket on MariaDB needs no password at all.