Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11, 11.4, 11.8, 12.3, 13.0, 12.3.3
-
Linux x86_64 host; official image `mariadb@sha256:dd9b303aed4f4890ed09f766d8ca9ddfd176c0c6f6267feff53b3192ec65a979`; server reports `12.3.3-MariaDB-ubu2404`, source revision `83e909fc2a0dbc394b4b683fb3fa2d7dcf26cc5e`; packaged Server Audit plugin 1.8.0.
Description
MariaDB masks `@@global.wsrep_sst_auth` when it is selected, and Server Audit
correctly masks a normal `CREATE USER ... IDENTIFIED BY` password. However, the
same audit plugin records the full `user:password` value from
`SET GLOBAL wsrep_sst_auth=...` in its QUERY event.
The test uses only synthetic credentials. It does not require a Galera peer or
an actual SST transfer.
Steps to reproduce
set -eu
|
IMAGE='mariadb@sha256:dd9b303aed4f4890ed09f766d8ca9ddfd176c0c6f6267feff53b3192ec65a979'
|
C='mdev-wsrep-audit-repro'
|
cleanup() { docker rm -f "$C" >/dev/null 2>&1 || true; }
|
trap cleanup EXIT
|
|
|
docker run --detach --name "$C" \
|
--env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1 \
|
"$IMAGE" \
|
--plugin-load-add=server_audit.so \
|
--server-audit-logging=OFF \
|
--server-audit-events=QUERY \
|
--server-audit-output-type=FILE \
|
--server-audit-file-path=/tmp/server_audit.log \
|
--server-audit-sync-log-file=ON
|
|
|
for i in $(seq 1 90); do
|
if docker exec "$C" mariadb --protocol=socket -uroot -NBe \
|
"SELECT @@port" 2>/dev/null | grep -qx 3306; then
|
break
|
fi
|
sleep 1
|
done
|
|
|
docker exec "$C" mariadb --protocol=socket -uroot -e "
|
SELECT PLUGIN_STATUS
|
FROM INFORMATION_SCHEMA.PLUGINS
|
WHERE PLUGIN_NAME='SERVER_AUDIT';
|
SET GLOBAL server_audit_logging=ON;
|
CREATE USER 'edbf_audit_control'@'localhost'
|
IDENTIFIED BY 'MDEV_SYNTHETIC_CONTROL_PASSWORD_20260908';
|
SET GLOBAL wsrep_sst_auth=
|
'edbf_sst_user:MDEV_SYNTHETIC_WSREP_SECRET_20260908';
|
SELECT @@global.wsrep_sst_auth;
|
"
|
|
|
sleep 1
|
docker exec "$C" grep -E \
|
'CREATE USER|wsrep_sst_auth|SELECT @@global.wsrep_sst_auth' \
|
/tmp/server_audit.log
|
|
Actual result
The SQL display value is masked:
@@global.wsrep_sst_auth
|
********
|
The audit log masks the normal account password but retains the complete SST
credential:
CREATE USER 'edbf_audit_control'@'localhost' IDENTIFIED BY *****
|
SET GLOBAL wsrep_sst_auth='edbf_sst_user:MDEV_SYNTHETIC_WSREP_SECRET_20260908'
|
SELECT @@global.wsrep_sst_auth
|
The SET statement succeeds and the server remains alive.
Expected result
Server Audit should redact the credential portion of `wsrep_sst_auth` in the
same way that MariaDB masks the variable display and masks passwords in account
management statements. The audit record should retain the operation and
variable name without retaining the secret.
Impact and boundary
The SST credential is copied into the audit log and can propagate to log
collectors, backups, or operators that do not otherwise need the live SST
password. The test used local root to execute `SET GLOBAL`; it did not determine
the minimum SQL privilege or demonstrate unprivileged operating-system access
to the audit file. No SST transfer was performed. Only MariaDB 12.3.3 was
tested. This report is researcher-reproduced and not yet maintainer-confirmed.