Enabling MySQL's general query log silently records plaintext passwords

A post on dev.to highlights a quiet security problem in a routine MySQL and MariaDB diagnostic setting: turning on the general query log produces a verbatim, plaintext record of every statement the server receives, and account-management statements such as CREATE USER ... IDENTIFIED BY 'password' land in it with the password fully intact.

The general query log is off by default. According to the dev.to post, setting general_log = 1 records each connection, each statement and each disconnection to a destination chosen by log_output, which selects a file, a table, or both, with the file path controlled by general_log_file. Statements are written exactly as received.

What ends up on disk

Alongside CREATE USER, the post notes that ALTER USER ... IDENTIFIED BY, GRANT ... IDENTIFIED BY and any application query containing a literal secret appear in the output as sent. Statements carrying session values, one-time tokens or personal data are captured as well.

The variable can also be switched on at runtime by any account holding SYSTEM_VARIABLES_ADMIN, with no edit to a configuration file. That matters for audits, the author argues: the important questions become who was able to enable the log and where the output actually went, and reviewing the config file answers neither because a dynamic setting overrides it.

Why leaving it on is risky

The post lays out three problems with running the log outside a bounded investigation:

• It becomes a credential store nobody classified as one. A password in a logged statement is disclosed to everyone who can read the file, and permissions on a data directory are normally tuned for the server process rather than for the secrecy of its contents.
• Breadth. The log holds every query from every account, including monitoring, reporting and application accounts, so a single reader of the file effectively sees the whole server.
• Retention. Rotated logs are copied to whatever destination the operator configured, and a copy sitting on a backup volume outlives the investigation that produced it.

Adjacent logs

The slow query log and the binary log record statements under defined conditions and can also capture literal values depending on the statement and the replication format, the post notes. The general log is the broadest of the three and the one most likely to be enabled by someone in a hurry.

A review checklist

The post recommends the following:

• Check the runtime values of general_log, log_output and general_log_file on every server, since the configuration file is not authoritative once a dynamic variable has been set.
• Scope any use: enable the log for a defined window, direct output to a controlled location, then disable and rotate it, recording who did both.
• Restrict SYSTEM_VARIABLES_ADMIN, which is effectively a disclosure capability.
• Protect the output as a secret, with file permissions matching the sensitivity of the statements inside, usually stricter than the data directory default.
• Review backups and log shipping for statements containing literals, and consider scrubbing before retention.
• For ongoing diagnostics, prefer the performance schema and the slow query log with long_query_time tuned to the workload, since both record less by default.

Why it matters

The general query log is a documented feature that works exactly as designed, and the post is careful to note that real exposure depends on whether it is enabled, who can read the output and what statements the workload sends. That is precisely what makes it a practical gotcha: it is the switch someone reaches for under pressure, it escapes configuration-file audits because it is dynamic, and it quietly turns routine administration into a persistent credential store whose copies spread through rotation and backups. Treating the log file as a secret, and the privilege to enable it as a disclosure capability, is the operational shift the post asks database administrators to make.