Secure a MariaDB Installation with mysql_secure_installation

You will finish with a reviewed MariaDB security configuration: local administrative access, no anonymous accounts, no unnecessary remote root accounts, and no default test database unless you have a documented reason to keep it. The installed command is MariaDB 10.11.14 from package mariadb-client 1:10.11.14-0ubuntu0.24.04.1. On this system, mysql_secure_installation is a symlink to mariadb-secure-installation.

Allow about fifteen minutes. You need a running MariaDB server, an account that can administer it, and a maintenance window if applications use the server. The script changes database accounts, privileges and possibly the test database. These are security-sensitive changes. Take a tested backup first, record any required remote administration path, and do not run the prompts mechanically on a shared or clustered server.

1. Confirm the command and the installed version

Start with read-only checks. You do not need elevated privileges to inspect the command or package:

$ command -v mysql_secure_installation
/usr/bin/mysql_secure_installation
$ readlink -f "$(command -v mysql_secure_installation)"
/usr/bin/mariadb-secure-installation
$ dpkg-query -W -f='${Package} ${Version}\n' mariadb-client
mariadb-client 1:10.11.14-0ubuntu0.24.04.1

The command accepts no required positional arguments. Its documented options are --basedir=DIR, --defaults-extra-file=FILE, --defaults-file=FILE and --no-defaults. The last three affect option-file loading and must be considered before the script connects. Do not add a guessed server option to the command line.

Checkpoint: the two names should resolve to the same installed script. If they do not, stop and read the help or manpage for the binary actually being used.

2. Preserve a recovery path

Before starting, confirm that you can administer the server using a known local method. MariaDB installations from 10.4 commonly use Unix socket authentication for the local root account, so a root password prompt does not always mean that you should create a new password. The exact account plugins and access rules on your server are the source of truth.

If you cannot log in as an administrator now, do not use the security script as a password-recovery tool. Arrange an approved recovery procedure first. Keep a backup and a copy of the current account and privilege state, taken through your normal database administration process. There is no single undo command for removing an account or dropping a database.

If this server is a Galera cluster, pause here. MariaDB documents that the script directly changes privilege tables and is not completely safe after the cluster is running. Use the cluster-specific procedure for your deployment, or run this before adding further nodes.

3. Start the interactive review

Run the script with the privilege needed to reach the local MariaDB socket. On a typical package installation that means:

$ sudo mariadb-secure-installation

Use mysql_secure_installation instead if that is the name in your operational documentation. It is an alias on this host. The script first asks for the current root password. If the installation has no root password, submit an empty response by pressing Enter. A blank response here is not an instruction to set a blank password later.

Read every question against your recorded requirements. The prompts can offer Unix socket authentication, a root password change, anonymous-user removal, remote-root restrictions, removal of the test database, and a privilege-table reload. The exact questions depend on the current MariaDB account state, so do not rely on a fixed transcript.

4. Choose root authentication deliberately

For a server administered locally, Unix socket authentication can be a good fit: operating-system access to the local socket is part of the control boundary, and applications do not need to use the root account. If your deployment requires password-based root login, set a strong unique password through the prompt and store it in the approved secret manager. Never put a real password in shell history, a ticket, a terminal recording or this article.

Do not change root authentication while guessing how automation works. First identify clients, backup jobs and deployment tools that might use root. Create a dedicated least-privilege database account for applications instead of making root usable from application code.

Checkpoint: after the authentication question, use the method you selected for a separate login test. For Unix socket authentication, the local client may be:

$ sudo mariadb --protocol=socket -e 'SELECT USER(), CURRENT_USER();'
USER()\tCURRENT_USER()
root@localhost\troot@localhost

The returned account names are host-specific evidence. If this command fails, stop before accepting further changes and investigate the authentication plugin and socket location.

5. Remove accounts and defaults you do not need

Answer yes to removing anonymous users unless you have a documented, tested reason to keep them. Anonymous accounts allow connections without a named database account and are not suitable for an ordinary production installation.

Answer yes to disallowing remote root login unless your administration design explicitly requires it. This does not prevent local administration, and it does not replace firewall rules, bind-address configuration or TLS. It narrows one high-value account so that remote administration must use an intentional account and connection path.

Answer yes to removing the test database if it is not part of a current, owned workload. The script removes the database and its associated access. This is destructive: confirm the database name is not being used for tests, demonstrations or an application before accepting the prompt. If it is needed, keep it only with an owner, access controls and a removal plan.

When asked to reload privilege tables, accept the reload after reviewing the preceding changes. The reload makes privilege changes take effect immediately. It does not restore an account or database removed earlier in the run.

6. Verify the resulting boundary

Finish the interactive run and look for its success messages. Then test the properties you actually chose, using read-only queries from an administrative connection:

$ sudo mariadb --protocol=socket -e "
SELECT User, Host, plugin
FROM mysql.user
ORDER BY User, Host;
SHOW DATABASES;
"

Output varies by MariaDB version and existing accounts. Do not expect the example rows verbatim. Check that anonymous rows are absent, root hosts match your remote-login decision, the selected root authentication plugin is present, and the test database is absent if you removed it. A successful script message alone is not proof that your intended policy matches the live account table.

Also test a real application account from the application host, and test the approved administrative path from the management host. Use a harmless query such as SELECT 1;. Do not test by attempting repeated bad passwords against a production service.

Common traps and recovery

Pressing Enter for the current password is appropriate only when the current root password is empty or the installation uses a method that does not require one. It is not a way around a failed authentication check. A non-zero connection error means you should stop and fix access through your normal recovery process.

Remote root access and network reachability are separate concerns. Removing remote root accounts does not close MariaDB's port or make an unsafe bind address safe. Review listening addresses, firewall policy and encrypted connections separately.

If you removed an account or the test database by mistake, do not invent a restore statement from memory. Restore the affected object from a tested backup or recreate it through your normal change process, then reapply least-privilege grants. If an application stopped connecting after an authentication change, revert through the documented account-management procedure and check its client configuration.