An appropriately privileged user (with SUPER privileges) could
execute shell commands as the uid of the mariadbd process
because the values of the system variable wsrep_sst_auth,
which can be modified at runtime, were not properly
sanitized when used to construct a shell command.
Combined rsync and mariabackup test cases and added
test case for incorrect values for wsrep_sst_auth.
This patch to mysqldump is only merged partially:
commit 666ff1db36
Author: Monty <monty@mariadb.org>
Date: Fri May 15 16:39:35 2026 +0300
MDEV-39519 Change mariadb-dump to use SHOW REPLICA STATUS instead of SHOW SLAVE STATUS
The functionality for --dump-slave cannot be merged as the underlying
functionality was removed in this commit:
commit 21c940d599
Author: ParadoxV5 <paradox.ver5@gmail.com>
Date: Thu Dec 4 21:22:20 2025 -0700
MDEV-37146 mariadb-dump: Replace SHOW SLAVE STATUS usage with information_schema.SLAVE_STATUS
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
Problem is that default path for SST is datadir and if there is not
enough space for all datafiles it fails.
In this patch wsrep_sst_tmp_dir configuration parameter is introduced.
User can now configure path where SST transfers datafiles in joiner
while operation is running. Additionally, if available transfer
size is compared to available disk space and if not necessary
big error is produced. When transfer is completed MariaBackup
will move datafiles to their correct locations.
Current rules for wsrep_sst_tmp_dir
* can be nullptr or empty and will not be used
* must be existing path and directory or not used
* may not be same as datadir or not used
* if total estimated SST payload available it should have enough available space
* similar to current behaviour temporal .sst directory is created
on path and this directory is removed after SST has finished
The upgrade SQL assumes the functions will resolve.
With a non-default path this isn't true and results in:
ERROR 1305 (42000) at line 3211: FUNCTION extract_schema_from_file_name does not exist
Resolve by setting PATH = 'CURRENT_SCHEMA' for the upgrade.
Idea thanks to Sergei Golubchik
Issue:
wsrep_sst_rsync.sh interpolated WSREP_SST_OPT_REMOTE_USER and
WSREP_SST_OPT_REMOTE_PSWD verbatim. Because both values originate from
the joiner side of the SST request, a newline in either could splice
an extra directive into the donor-written stunnel.conf (silently
downgrading peer-cert verification) or an extra line into the rsync
magic file. MDEV-39413 had introduced safe() for the same threat class
in wsrep_sst_mariabackup but did not extend it to the rsync script.
Solution:
Routing the rsync interpolations through safe() closes the gap, and
extending safe() to also reject tab and newline ensures multi-line
values cannot survive into a config-file heredoc.
scripts/fill_help_tables.sql from
https://github.com/mariadb-corporation/mariadb-docs/ as of
3fb208fcdfed06beb52ef9e305017de2387ff012
Other URL changes are taken from the HTTP redirection URL
from the old KB.
Some test cases where impacted:
* ps_missed_cmds{,_bin_prot} - used a topic_id of 0 that is
now used, used MAX_INT instead.
* range_notembedded used the help data as a test case. As its not
a stable table data, replaces with static data. Test case valid
by ensuring the ANALYZE EXPLAIN and optimizer trace had the same
structure. Also valided the MDEV-24739/MDEV-25069 bug fixes from
where the test case originaled, when reverted, exhibited the
previous behavour before the bug fixes.
In the build directory the galera sst scripts where
without executable permissions.
This is as a result of [1]. In this patch removing
WSREP_SST_SCRIPTS out of SERVER_SCRIPTS resulting
in the missing from BIN_SCRIPTS which all had an
explicit chmod executed on the script.
Corrected by explictly changing the permission on
the script as would have been done previously.
Thanks Marko Mäkelä for reporting.
[1] efb70285b908be57cc50934a6c8f994773d7583
On non-Windows systems, use the invoking user's login name as the
default MariaDB username instead of hardcoding root.
Resolve the username from getpwuid($<), falling back to LOGNAME, USER,
and finally root. Keep the existing root default on Windows.
This makes mytop behave more like the mysql and mariadb clients and
avoids confusing authentication failures on systems where local socket
access is configured for the OS user rather than root.
Also update the connection error text and POD to describe the actual
default behavior.
introduce safe() wrapper for parameters that can later be interpolated
into command line.
Use as
- var="foo$BAR"
+ var="foo$(safe BAR)"
A parameter is safe, if it contains no spaces, single quotes or backticks
The wsrep SST scripts weren't part of the server-galera
component so CPack didn't put them in the MariaDB-server-galera
package.
The previous existing per file component wasn't used so this
was simplified.
- XXH is significantly faster than both MD5 and SHA-256
- Here we use the 128-bit XXH3
- Keep DIGEST_HASH_SIZE at 16 bytes (same as MD5)
- Reduce COL_DIGEST_SIZE to 32 chars
- Keep DIGEST columns as VARCHAR(32)
Following the previous commit, we apply the same
to RPM.
Add new package Mariadb-server-galera to RPM build
recude mariadb-server package dependencies.
Galera cluster scripts and libraries are currently
in package mariadb-server. Move Galera cluster
scripts and libraries to new package mariadb-server-galera
as most of the people does not need them and
it allows to slim down mariadb-server package
The MariaDB-test package unlike its Debian
equal, didn't depend on the MariaDB-server
(and now it does), except if WITH_WSREP is
specified in which case it depends on the
MariaDB-server-galera package
Also from a865a7c23b
lsof, socat and pv are RECOMMENDS.
* lsof/socat - when selinux is enabled, these aren't used
* pv - the galera sst scripts will silently ignore its absence
Updated/Edited by: Daniel Black <daniel@mariadb.org>
Definition
==========
Implement the SET PATH statement.
```
SET PATH 'schema1, schema2, schema3';
```
Function
--------
In MariaDB, the SQL-path will also be used to lookup packages in
package routine invocations, so the following script:
SET PATH 'sys';
SELECT UTL_ENCODE.BASE64_DECODE('data');
invokes SYS.UTL_ENCODE.BASE64_DECODE('data'), i.e. the function
BASE64_DECODE() in the packge UTL_ENCODE in the database SYS
(if such package and package routine exist).
MariaDB implementation details
------------------------------
The ticket's requirement stated the grammar should support delimited
identifiers with backticks or double quotes within the string quote,
ie: the single tick. A simple parser was implemented to handle this
requirement in Sql_path::from_text.
Only 16 schemas are supported per session - we do not want too many
schemas in the path anyway since it will impact performance. This also
means that the path cache is a simple static array for easier memory
management.
In case if the view mysql.user was created (e.g. in 10.6) with a
pre- 18edb0959f server with an unexpected
character_set_client or collation_connection, e.g.
utf8mb3 and utf8mb3_general_ci, mysql_upgrade did not fix it to the
expected latin1 and latin1_swedish_ci.
Since 11.8 this could often lead to "Illegax mix of collations" errors
when querying mysql.user, because since 11.8 the default collation for
utf8mb3 is utf8mb3_uca1400_ai_ci, according to the default
@@character_set_collations. For consistency, it's better to fix the
problem starting from 11.4.
For example:
MariaDB [test]> select user,host,is_role from
-> mysql.user where is_role='N';
ERROR 1267 (HY000): Illegal mix of collations (utf8mb3_general_ci,COERCIBLE)
and (utf8mb3_uca1400_ai_ci,COERCIBLE) for operation '='
Fixing mariadb_system_tables_fix.sql to drop the view if it has non-standard
character set or collations, so it gets recreated again correctly by
the CREATE statement in mariadb_system_tables.sql
