[MXS-684] Password field still used with MySQL 5.7 Created: 2016-04-22  Updated: 2016-04-29  Resolved: 2016-04-25

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: 1.4.1
Fix Version/s: 1.4.2

Type: Bug Priority: Minor
Reporter: Onno Steenbergen Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None
Environment:

Debian GNU/Linux 8.2 (jessie)
MaxScale 1.4.1
MySQL 5.7.12-log



 Description   

2016-04-22 10:59:31 info : Started session [0] for Read-Only Service service
2016-04-22 10:59:31 error : Read-Write Service: Error: Failed to query from mysql.user table. MySQL error message: Unknown column 'password' in 'field list'
2016-04-22 10:59:31 debug : Dbusers : Loading data from backend database with Master role [10.0.3.26:3306] for service [Read-Write Service]
2016-04-22 10:59:31 error : Failed to retrieve database names:
2016-04-22 10:59:31 error : Read-Write Service: Unable to load database grant information, MaxScale authentication will proceed without including database permissions. See earlier error messages for user 'manager' for more information.
2016-04-22 10:59:31 debug : Loaded 0 MySQL Database Names for service [Read-Write Service]

In server/core/dbusers.c the function check_service_permissions still uses the hardcoded password field:

if (mysql_query(mysql, "SELECT user, host, password,Select_priv FROM mysql.user limit 1") != 0)

 Comments   
Comment by markus makela [ 2016-04-25 ]

The permission check queries now use the proper column name.

Comment by Gabe Martin-Dempesy [ 2016-04-29 ]

This change is causing 1.4.2 to regularly Fatal signal 11 during startup. gdb is giving me the following backtrace:

(gdb) bt
 
#0  0x00007f44762c43a8 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
 
#1  0x00007f4476dd64f2 in check_service_permissions (service=0x1dcc250) at /home/vagrant/workspace/server/core/dbusers.c:2677
 
#2  0x00007f4476df3019 in serviceStart (service=0x1dcc250) at /home/vagrant/workspace/server/core/service.c:477
 
#3  0x00007f4476df3189 in serviceStartAll () at /home/vagrant/workspace/server/core/service.c:540
 
#4  0x000000000040683c in main (argc=5, argv=0x7fffba255398) at /home/vagrant/workspace/server/core/gateway.c:1917
 
(gdb) f 1
 
#1  0x00007f4476dd64f2 in check_service_permissions (service=0x1dcc250) at /home/vagrant/workspace/server/core/dbusers.c:2677
 
warning: Source file is more recent than executable.
 
2677	    const char* query_pw = strstr(server->server->server_string, "5.7.") ?
 
(gdb) p server->server->server_string
 
$36 = 0x0

It looks like server_string is NULL, and this is a race against the monitor thread which normally sets the string?

Comment by Gabe Martin-Dempesy [ 2016-04-29 ]

I see this is actually already fixed in a separate release branch for 1.4.3: https://github.com/mariadb-corporation/MaxScale/commit/b26592c8661750719d540a7b6fc96535dfb7d428

Markus, do you have a short summary on the MaxScale's branch workflow? I was expecting to find the latest changes in 'develop', but it looks like these 1.4.x release are coming off of 'master', which diverged from 'develop' in early March.

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