[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.
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:
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 |