[MXS-4256] impossible to hash nosqlprotocol password in mxs config file Created: 2022-08-24  Updated: 2023-01-30  Resolved: 2023-01-30

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

Type: Bug Priority: Major
Reporter: Sylvain ARBAUDIE Assignee: Johan Wikman
Resolution: Cannot Reproduce Votes: 0
Labels: None


 Description   

it is impossible to hash the nosqlrotocol.password as a regular maxscale service user.

example : 

maxpasswd /var/lib/maxscale aBcd_123

gives a hash

when replacing plain text password with said hash in this : 

[mcs_mongo]
 
type=listener
 
service=Read-Write-Service
 
protocol=nosqlprotocol
 
nosqlprotocol.user=mongo_test
 
nosqlprotocol.password=HASH
 
port=27017

after restart all tries to insert a new document end up with this error message : 

db.runCommand({insert: "mongo_collection", documents: [{_id: 1, "hello": "world"}]});
 
 
 
uncaught exception: Error: error doing query: failed: network error while attempting to run command 'insert' on host '127.0.0.1:27017'  :
 
 
 
DB.prototype.runCommand@src/mongo/shell/db.js:177:19

with password in clear text, everything works as intended.

 Comments   
Comment by Johan Wikman [ 2022-08-25 ]

I just tried that and it seems to work. Could you please verify that the user and the encrypted password work when used in the service. To rule out the case that the password was encrypted using another key than the one MaxScale uses for decrypting it.

Comment by Sylvain ARBAUDIE [ 2022-08-29 ]

you mean that both the service user that connects to mariadb and the listener user that connects to mongo have to be the same and thus we should be using the same hash ?

Comment by Johan Wikman [ 2022-08-29 ]

No, you don't need to use the same hash. However, this worked fine for me, it would be good to verify that the used hash works in some other place. To rule out the possibility that it was created using another key than the one MaxScale uses for decrypting it.

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