[MXS-3440] replication_password silently truncates password longer than 41 characters Created: 2021-03-13  Updated: 2021-07-12  Resolved: 2021-07-12

Status: Closed
Project: MariaDB MaxScale
Component/s: N/A
Affects Version/s: 2.5.5
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Vitaly Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Environment:

Debian buster


 Description   

Hi, i noticed that when one of the slave servers goes down, after restart i am getting "Access denied" error in the SLAVE STATUS. Upon further investigation it looks like replication_password is limited to 41 characters and will silently truncate password and update the slave with the wrong truncated password.
Before storing passwords in maxscale.cnf they were encrypted with maxpasswd "abc abc abc".

 Comments   
Comment by markus makela [ 2021-03-15 ]

Can you give us an example configuration that reproduces the problem?

Comment by Vitaly [ 2021-03-15 ]

Hi,
Maxscale 2.5.5 config is as follows:
[monitor]
type=monitor
module=mariadbmon
servers=dbA,dbB
user=orchestrator
password=PWHASHXXXXXXX
monitor_interval=2s
enforce_read_only_slaves=true
enforce_simple_topology=true
auto_failover=true
auto_rejoin=true
replication_user=replication
replication_password=PWHASHXXXXXXX
verify_master_failure=true
master_failure_timeout=180
failcount=5
script=/opt/runtime/maxscaleNotification.sh
events=master_down,slave_down,master_up,slave_up

Password hash is prepared using maxpasswd "somePassword that is more than 41 characters long"
If using diceware password, 41 character long password very common.

Backend db is 10.4.15-MariaDB.
Whenever a failover happens slave database reports Access denied in SHOW SLAVE STATUS
Truncated password can also be seen in master.info

It seems that it doesn't happen when a manual switchover is issues, only when master goes down.

Comment by markus makela [ 2021-03-19 ]

Tested with the user test with the password this_is_a_very_long_password_that_is_encrypted that is 46 characters long unencrypted and 128 characters when encrypted. The code seems to work as expected.

Is the .secrets file from an older MaxScale release? If you rehash the password with a new encryption key generated with maxkeys does the problem persist?

Comment by Vitaly [ 2021-03-19 ]

Thats strange, encrypted hash was initially from a different host but same version, later on i was regenerated with maxkeys as well.
I will try to setup a new environment and retest everything next week and hopefully come back with more details.

Comment by markus makela [ 2021-07-12 ]

Closing as Cannot Reproduce since we weren't able to reproduce this. If you can create a reproducible test case, we'll reopen this.

Generated at Thu Feb 08 04:21:26 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.