[MDEV-10956] Strict Password Validation Breaks Replication Created: 2016-10-05  Updated: 2017-01-17  Resolved: 2017-01-17

Status: Closed
Project: MariaDB Server
Component/s: Authentication and Privilege System
Affects Version/s: 10.1.17
Fix Version/s: 10.1.21

Type: Bug Priority: Critical
Reporter: Will Fong Assignee: Alexey Botchkov
Resolution: Fixed Votes: 2
Labels: None

Sprint: 10.1.19, 10.1.20, 10.1.21

 Description   

With strict password validation being enabled by default (and also have a password validation plugin enabled), changing a password will break replication.

SET PASSWORD FOR 'w'@'localhost' = PASSWORD('PLAINtext-password!!99');

Last_SQL_Error: Error 'The MariaDB server is running with the --strict-password-validation option so it cannot execute this statement' on query. Default database: ''. Query: 'SET PASSWORD FOR 'w'@'localhost'='*4045DC6C4FBF96E66F67118A73C6A85EB2BF28A9''

The password is written to the binary log as a hash, which strict password validation prevents.

A possible workaround seems to be to disable strict password validation and then re-enable it after the password change events:

STOP SLAVE;
SET GLOBAL strict_password_validation = OFF;
START SLAVE;
-- wait
SET GLOBAL strict_password_validation = ON;

It seems like there should be a "exemption" of some sort in the password validation plugins to allow these events from a master so slaves don't break.



 Comments   
Comment by Richard Stracke [ 2016-11-17 ]

Bug is already in 10.1.16

Comment by Chunli Yao [ 2016-11-17 ]

the same bug impacts Galera cluster replication by using xtrabackup as well(version 10.1.17).

Comment by Alexey Botchkov [ 2017-01-15 ]

I decided to turn off password validation in slave threads completely. Well maybe we should still validate plaintext passwords there, but i don't feel so at the moment.

http://lists.askmonty.org/pipermail/commits/2017-January/010432.html

Comment by Alexey Botchkov [ 2017-01-17 ]

http://lists.askmonty.org/pipermail/commits/2017-January/010446.html

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