[MDEV-31470] When set at runtime, wsrep_sst_method accepts any value Created: 2023-06-13  Updated: 2023-10-24  Resolved: 2023-10-24

Status: Closed
Project: MariaDB Server
Component/s: Galera
Affects Version/s: 10.4.30
Fix Version/s: 10.4.32, 10.5.23, 10.6.16, 10.10.7, 10.11.6, 11.0.4, 11.1.3, 11.2.2, 11.3.1

Type: Bug Priority: Critical
Reporter: Federico Razzoli Assignee: Julius Goryavsky
Resolution: Fixed Votes: 1
Labels: Papercut, beginner-friendly

Issue Links:
Relates
relates to MDEV-23884 donor uses invalid SST methods Closed

 Description   

Invalid values are accepted:

MariaDB [(none)]> set global wsrep_sst_method := 'handwrite rows and send them via post';
Query OK, 0 rows affected (0.000 sec)
 
MariaDB [(none)]> select @@wsrep_sst_method;
+---------------------------------------+
| @@wsrep_sst_method                    |
+---------------------------------------+
| handwrite rows and send them via post |
+---------------------------------------+
1 row in set (0.000 sec)



 Comments   
Comment by Daniel Black [ 2023-06-13 ]

Well spotted.

Like your example method too. Need more fun things in bug reports

Comment by Seppo Jaakola [ 2023-10-18 ]

wsep_sst_method is checked in donor node when SST request arrives. This is the proper location for enforcing the validity of the SST method, from the vulnerability point of view.

It is also possible to check the wsrep_sst_method whenever the variable is changed and restrict accepted values in similar way as happens in donor processing. This has no other effect though, but stop the super user experimenting with this variable.

Comment by Seppo Jaakola [ 2023-10-18 ]

a PR has been submitted to carry out same validity checks on wsrep_sst_method changing as what the donor node does for incoming SST request

Comment by Federico Razzoli [ 2023-10-18 ]

The benefit is that the check will prevent mistakes.

Comment by Julius Goryavsky [ 2023-10-24 ]

Fix merged with head revision: https://github.com/MariaDB/server/commit/c7feacb0dee696cf602a19da32d1069d0b0ff7c4

Generated at Thu Feb 08 10:24:07 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.