[MXS-1715] "MySQL server has gone away" when using PAM_Auth with pam_unix local users having different local passwords Created: 2018-03-12  Updated: 2018-03-18  Resolved: 2018-03-18

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

Type: Bug Priority: Major
Reporter: Hartmut Holzgraefe Assignee: markus makela
Resolution: Not a Bug Votes: 0
Labels: None


 Description   

When using PAM_Auth with maxscale and mariadb running on different hosts and both using pam_unix.so, but having different local passwords for a given unix user, connecting with the maxscale side password succeeds, but every SQL command ends with

Here the user "pamuser" has password "geheim" on the server running maxscale, but "secret" on the server running mariadb:

$ mysql -h 127.0.0.1 -p -P 5006 -u pamuser -pgeheim test 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 39
Server version: 10.2.12 2.2.3-maxscale
 
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
MySQL [test]> show tables;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    40
Current database: test
 
ERROR 2013 (HY000): Lost connection to MySQL server during query
MySQL [test]> 

The MaxScale log shows this right after connection:

2018-03-12 21:35:27   error  : (42) [mariadbbackend] Invalid authentication message from backend 'server1'. Error code: 1045, Msg : #28000Access denied for user 'pamuser'@'10.0.42.12' (using password: NO)
2018-03-12 21:35:27   notice : (42) [PAMAuth] Loaded 4 users for service RWSp.
2018-03-12 21:35:27   error  : [mariadbbackend] Unable to write to backend 'server1' due to authentication failure. Server in state RUNNING MASTER.

Shouldn't maxscale simply report an "Access denied" error in this case as the MariaDB backend clearly reported that when MaxScale tried to connect?



 Comments   
Comment by markus makela [ 2018-03-13 ]

As MaxScale asynchronously authenticates the client before even connecting to the backend servers, this is currently expected behavior. We actually do send an error message to the client but it should only show up once the client performs another command.

The exact error message the client should get is:

Authentication with backend failed. Session will be closed.

A quick look at the code reveals that when the client is attempting to write to a backend server, it doesn't appear to send the error. I think we should write it to the client even in this case.

Comment by markus makela [ 2018-03-18 ]

The command line client doesn't appear to relay the error message to the user even if one is sent by MaxScale. This does make sense as the connection is closed right after the message is sent.

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