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`; `mariadb-backup` and server report 12.3.3; server source revision `83e909fc2a0dbc394b4b683fb3fa2d7dcf26cc5e`.
Description
When `file_key_management_filekey` is configured with a direct passphrase,
`mariadb-backup --backup` retrieves that value and copies it into two additional
plaintext sinks: its diagnostic output and the generated `backup-my.cnf`.
Therefore a secret intended to unlock the encrypted key file is replicated into
backup logs and every backup directory.
The test uses only synthetic key material.
Steps to reproduce
set -eu
|
IMAGE='mariadb@sha256:dd9b303aed4f4890ed09f766d8ca9ddfd176c0c6f6267feff53b3192ec65a979'
|
C='mdev-backup-filekey-repro'
|
D=$(mktemp -d)
|
SECRET='MDEV_SYNTHETIC_FILEKEY_SECRET_20260908'
|
cleanup() {
|
docker rm -f "$C" >/dev/null 2>&1 || true
|
rm -r "$D" >/dev/null 2>&1 || true
|
}
|
trap cleanup EXIT
|
|
|
printf '%s\n' '1;0123456789ABCDEF0123456789ABCDEF' > "$D/keys.plain"
|
openssl enc -aes-256-cbc -md sha1 -salt \
|
-pass pass:"$SECRET" -in "$D/keys.plain" -out "$D/keys.enc"
|
chmod 0644 "$D/keys.enc"
|
|
|
docker run --detach --name "$C" \
|
--mount type=bind,src="$D/keys.enc",dst=/keys.enc,readonly \
|
--env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1 \
|
"$IMAGE" \
|
--plugin-load-add=file_key_management.so \
|
--file-key-management-filename=/keys.enc \
|
--file-key-management-filekey="$SECRET"
|
|
|
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 -NBe \
|
"SELECT PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS
|
WHERE PLUGIN_NAME='file_key_management'"
|
|
|
docker exec "$C" mariadb-backup --backup --user=root \
|
--socket=/run/mysqld/mysqld.sock --target-dir=/tmp/backup \
|
>"$D/backup.out" 2>&1
|
|
|
echo 'Output sink:'
|
grep -F "$SECRET" "$D/backup.out"
|
echo 'Generated configuration sink:'
|
docker exec "$C" grep -F "$SECRET" /tmp/backup/backup-my.cnf
|
|
Actual result
The backup succeeds. The complete passphrase appears in both locations:
Encryption plugin parameter : '--file_key_management_filekey=MDEV_SYNTHETIC_FILEKEY_SECRET_20260908'
|
file_key_management_filekey=MDEV_SYNTHETIC_FILEKEY_SECRET_20260908
|
A control run configured with
`file_key_management_filekey=FILE:/path/to/secret-file` preserved only the file
reference; the secret file contents did not appear in either sink.
Expected result
`mariadb-backup` must not print a file-key passphrase. It should also avoid
persisting the passphrase in `backup-my.cnf`; it can omit the value, redact it,
or require a separately protected secret reference during prepare or restore.
Impact and boundary
Backup logs and backup directories may have different readers, retention, and
copy destinations from the original server configuration. Copying the
passphrase into both locations expands access to the data-at-rest encryption
secret. This test does not establish the default permissions of every backup
deployment, and `FILE:` is an available mitigation. Only MariaDB 12.3.3 was
tested. This report is researcher-reproduced and not yet maintainer-confirmed.