[MDEV-16396] Perl's DBD::MySQL does not read SSL settings from [client] configuration group with MariaDB libmysqlclient.so Created: 2018-06-04  Updated: 2020-08-25  Resolved: 2018-06-07

Status: Closed
Project: MariaDB Server
Component/s: Scripts & Clients, SSL
Affects Version/s: 5.5, 10.0, 10.1
Fix Version/s: 5.5.61, 10.0.36, 10.1.34

Type: Bug Priority: Major
Reporter: Geoff Montee (Inactive) Assignee: Vladislav Vaintroub
Resolution: Fixed Votes: 0
Labels: upstream-fixed

Attachments: File mariadb-compat-10.1.33-strace.tar.gz     File mariadb-libs-5.5.56-strace.tar.gz     File mysql-compat-5.6.40-strace.tar.gz    
Issue Links:
Problem/Incident
is caused by MDEV-10246 ssl-* have no effect without mysql_ss... Closed
Relates
relates to CONC-340 ssl-* options in config have no effec... Closed

 Description   

Let's say that we have the following configuration file:

[ec2-user@ip-172-30-0-136 ~]$ cat ~/.my.cnf
[client]
ssl_cert=/home/ec2-user/server-cert.pem
ssl_key=/home/ec2-user/server-key.pem
ssl_ca=/home/ec2-user/ca.pem

The normal "mysql" command-line client definitely uses these SSL settings:

[ec2-user@ip-172-30-0-136 ~]$ mysql -h 172.30.0.249 -u maxscale -ppassword
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 18
Server version: 10.1.31-MariaDB MariaDB Server
 
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
MariaDB [(none)]> SHOW SESSION STATUS LIKE 'Ssl_cipher';
+---------------+---------------------------+
| Variable_name | Value                     |
+---------------+---------------------------+
| Ssl_cipher    | DHE-RSA-AES256-GCM-SHA384 |
+---------------+---------------------------+
1 row in set (0.00 sec)

However, when using a program that relies on Perl's DBD::MySQL, such as innotop, it appears that these SSL settings are not used when the underlying libmysqlclient.so is provided by MariaDB. In contrast, if the underlying libmysqlclient.so is provided by MySQL, then it does use the SSL settings.

I confirmed this by running innotop with strace using various versions of libmysqlclient.so in the following way:

strace -o<some path>/strace.out -ff innotop -h 172.30.0.249 -u maxscale -p password

The results show that only MySQL's libmysqlclient.so reads the PEM certificate files, even though all versions of the libmysqlclient.so read the actual configuration file.

mariadb-libs 5.5.56 from the RHEL 7's standard yum repository:

[ec2-user@ip-172-30-0-136 ~]$ grep "cnf" mariadb-libs-5.5.56-strace/*
mariadb-libs-5.5.56-strace/strace.out.1498:stat("/etc/mysql/my.cnf", 0x7ffd1d3eba60) = -1 ENOENT (No such file or directory)
mariadb-libs-5.5.56-strace/strace.out.1498:stat("/etc/my.cnf", {st_mode=S_IFREG|0644, st_size=570, ...}) = 0
mariadb-libs-5.5.56-strace/strace.out.1498:open("/etc/my.cnf", O_RDONLY)           = 6
mariadb-libs-5.5.56-strace/strace.out.1498:openat(AT_FDCWD, "/etc/my.cnf.d/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 7
mariadb-libs-5.5.56-strace/strace.out.1498:stat("/etc/my.cnf.d/client.cnf", {st_mode=S_IFREG|0644, st_size=295, ...}) = 0
mariadb-libs-5.5.56-strace/strace.out.1498:open("/etc/my.cnf.d/client.cnf", O_RDONLY) = 7
mariadb-libs-5.5.56-strace/strace.out.1498:stat("/etc/my.cnf.d/mysql-clients.cnf", {st_mode=S_IFREG|0644, st_size=232, ...}) = 0
mariadb-libs-5.5.56-strace/strace.out.1498:open("/etc/my.cnf.d/mysql-clients.cnf", O_RDONLY) = 7
mariadb-libs-5.5.56-strace/strace.out.1498:stat("/home/ec2-user/.my.cnf", {st_mode=S_IFREG|0664, st_size=117, ...}) = 0
mariadb-libs-5.5.56-strace/strace.out.1498:open("/home/ec2-user/.my.cnf", O_RDONLY) = 6
[ec2-user@ip-172-30-0-136 ~]$ grep "pem" mariadb-libs-5.5.56-strace/*

MariaDB-shared + MariaDB-compat + MariaDB-common 10.1.33 from RHEL 7 RPMs from mariadb.org:

[ec2-user@ip-172-30-0-136 ~]$ grep "cnf" mariadb-compat-10.1.33-strace/*
mariadb-compat-10.1.33-strace/strace.out.1687:stat("/etc/my.cnf", {st_mode=S_IFREG|0644, st_size=202, ...}) = 0
mariadb-compat-10.1.33-strace/strace.out.1687:open("/etc/my.cnf", O_RDONLY|O_CLOEXEC) = 6
mariadb-compat-10.1.33-strace/strace.out.1687:openat(AT_FDCWD, "/etc/my.cnf.d/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 7
mariadb-compat-10.1.33-strace/strace.out.1687:stat("/etc/my.cnf.d/client.cnf", {st_mode=S_IFREG|0644, st_size=295, ...}) = 0
mariadb-compat-10.1.33-strace/strace.out.1687:open("/etc/my.cnf.d/client.cnf", O_RDONLY|O_CLOEXEC) = 7
mariadb-compat-10.1.33-strace/strace.out.1687:stat("/home/ec2-user/.my.cnf", {st_mode=S_IFREG|0664, st_size=117, ...}) = 0
mariadb-compat-10.1.33-strace/strace.out.1687:open("/home/ec2-user/.my.cnf", O_RDONLY|O_CLOEXEC) = 6
[ec2-user@ip-172-30-0-136 ~]$ grep "pem" mariadb-compat-10.1.33-strace/*

MySQL-shared + MySQL-shared-compat 5.6.40 from RHEL 7 RPMs from dev.mysql.com:

[ec2-user@ip-172-30-0-136 ~]$ grep "cnf" mysql-compat-5.6.40-strace/*
mysql-compat-5.6.40-strace/strace.out.1732:stat("/etc/my.cnf", 0x7fffb8f2d060)     = -1 ENOENT (No such file or directory)
mysql-compat-5.6.40-strace/strace.out.1732:stat("/etc/mysql/my.cnf", 0x7fffb8f2d060) = -1 ENOENT (No such file or directory)
mysql-compat-5.6.40-strace/strace.out.1732:stat("/usr/etc/my.cnf", 0x7fffb8f2d060) = -1 ENOENT (No such file or directory)
mysql-compat-5.6.40-strace/strace.out.1732:stat("/home/ec2-user/.my.cnf", {st_mode=S_IFREG|0664, st_size=117, ...}) = 0
mysql-compat-5.6.40-strace/strace.out.1732:open("/home/ec2-user/.my.cnf", O_RDONLY) = 6
mysql-compat-5.6.40-strace/strace.out.1732:stat("/home/ec2-user/.mylogin.cnf", 0x7fffb8f2d060) = -1 ENOENT (No such file or directory)
[ec2-user@ip-172-30-0-136 ~]$ grep "pem" mysql-compat-5.6.40-strace/*
mysql-compat-5.6.40-strace/strace.out.1732:open("/home/ec2-user/ca.pem", O_RDONLY) = 7
mysql-compat-5.6.40-strace/strace.out.1732:open("/home/ec2-user/server-cert.pem", O_RDONLY) = 7
mysql-compat-5.6.40-strace/strace.out.1732:open("/home/ec2-user/server-key.pem", O_RDONLY) = 7

As you can see, only MySQL's libmysqlclient.so caused innotop to read the PEM certificate files. Is this intentional, or a bug?

I've attached the strace output.

In addition to innotop, I've also been informed that this also affects Percona Toolkit, since those tools are also Perl programs that rely on DBD::MySQL.



 Comments   
Comment by Vladislav Vaintroub [ 2018-06-05 ]

GeoffMontee I think, you can get clients to ssl by additional ssl=1 in the config file
use of any other SSL parameter does not automagically switch it on , as per MDEV-10246

Comment by Elena Stepanova [ 2018-06-05 ]

Confirming and setting affected versions based on the above.

Comment by Geoff Montee (Inactive) [ 2018-06-05 ]

Thanks for the idea, wlad. It doesn't look like that forced the client to read the pem files either though:

[ec2-user@ip-172-30-0-136 ~]$ cat ~/.my.cnf
[client]
ssl=1
ssl_cert=/home/ec2-user/server-cert.pem
ssl_key=/home/ec2-user/server-key.pem
ssl_ca=/home/ec2-user/ca.pem
 
[ec2-user@ip-172-30-0-136 ~]$ grep "cnf" mariadb-compat-10.1.33-ssl_1-strace/*
mariadb-compat-10.1.33-ssl_1-strace/strace.out.1188:stat("/etc/my.cnf", {st_mode=S_IFREG|0644, st_size=202, ...}) = 0
mariadb-compat-10.1.33-ssl_1-strace/strace.out.1188:open("/etc/my.cnf", O_RDONLY|O_CLOEXEC) = 6
mariadb-compat-10.1.33-ssl_1-strace/strace.out.1188:openat(AT_FDCWD, "/etc/my.cnf.d/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 7
mariadb-compat-10.1.33-ssl_1-strace/strace.out.1188:stat("/etc/my.cnf.d/client.cnf", {st_mode=S_IFREG|0644, st_size=295, ...}) = 0
mariadb-compat-10.1.33-ssl_1-strace/strace.out.1188:open("/etc/my.cnf.d/client.cnf", O_RDONLY|O_CLOEXEC) = 7
mariadb-compat-10.1.33-ssl_1-strace/strace.out.1188:stat("/home/ec2-user/.my.cnf", {st_mode=S_IFREG|0664, st_size=123, ...}) = 0
mariadb-compat-10.1.33-ssl_1-strace/strace.out.1188:open("/home/ec2-user/.my.cnf", O_RDONLY|O_CLOEXEC) = 6
[ec2-user@ip-172-30-0-136 ~]$ grep "pem" mariadb-compat-10.1.33-ssl_1-strace/*
[ec2-user@ip-172-30-0-136 ~]$ sudo rpm -qa | grep -i maria
mariadb-5.5.56-2.el7.x86_64
MariaDB-common-10.1.33-1.el7.centos.x86_64
MariaDB-shared-10.1.33-1.el7.centos.x86_64
MariaDB-compat-10.1.33-1.el7.centos.x86_64

Comment by Geoff Montee (Inactive) [ 2018-06-05 ]

I also checked MySQL 5.5.60, and that seems to read the pem files in the same way that MySQL 5.6.40 does.

[ec2-user@ip-172-30-0-136 ~]$ cat ~/.my.cnf
[client]
ssl_cert=/home/ec2-user/server-cert.pem
ssl_key=/home/ec2-user/server-key.pem
ssl_ca=/home/ec2-user/ca.pem
 
[ec2-user@ip-172-30-0-136 ~]$ grep "cnf" mysql-compat-5.5.60-strace/*
mysql-compat-5.5.60-strace/strace.out.1283:stat("/etc/my.cnf", 0x7ffcfeccb090)     = -1 ENOENT (No such file or directory)
mysql-compat-5.5.60-strace/strace.out.1283:stat("/etc/mysql/my.cnf", 0x7ffcfeccb090) = -1 ENOENT (No such file or directory)
mysql-compat-5.5.60-strace/strace.out.1283:stat("/usr/etc/my.cnf", 0x7ffcfeccb090) = -1 ENOENT (No such file or directory)
mysql-compat-5.5.60-strace/strace.out.1283:stat("/home/ec2-user/.my.cnf", {st_mode=S_IFREG|0664, st_size=117, ...}) = 0
mysql-compat-5.5.60-strace/strace.out.1283:open("/home/ec2-user/.my.cnf", O_RDONLY) = 6
[ec2-user@ip-172-30-0-136 ~]$ grep "pem" mysql-compat-5.5.60-strace/*
mysql-compat-5.5.60-strace/strace.out.1283:open("/home/ec2-user/ca.pem", O_RDONLY) = 7
mysql-compat-5.5.60-strace/strace.out.1283:open("/home/ec2-user/server-cert.pem", O_RDONLY) = 7
mysql-compat-5.5.60-strace/strace.out.1283:open("/home/ec2-user/server-key.pem", O_RDONLY) = 7
[ec2-user@ip-172-30-0-136 ~]$ rpm -qa | grep -i mysql
perl-DBD-MySQL-4.023-6.el7.x86_64
MySQL-shared-5.5.60-1.el7.x86_64
MySQL-shared-compat-5.5.60-1.el7.x86_64

Comment by Vladislav Vaintroub [ 2018-06-07 ]

Fixed with MDEV-10246

Comment by Geoff Montee (Inactive) [ 2018-06-07 ]

Thanks, wlad. I think "Fix Versions" for this one is wrong. Shouldn't it be 5.5.61, 10.0.36, 10.1.34 to match MDEV-10246?

Comment by Geoff Montee (Inactive) [ 2018-06-07 ]

I just did a quick test, and it does look like 10.2 is also affected:

[ec2-user@ip-172-30-0-136 ~]$ cat ~/.my.cnf
[client]
ssl_cert=/home/ec2-user/server-cert.pem
ssl_key=/home/ec2-user/server-key.pem
ssl_ca=/home/ec2-user/ca.pem
 
[ec2-user@ip-172-30-0-136 ~]$ grep "cnf" mariadb-compat-10.2.15-strace/*
mariadb-compat-10.2.15-strace/strace.out.1186:stat("/etc/my.cnf", {st_mode=S_IFREG|0644, st_size=202, ...}) = 0
mariadb-compat-10.2.15-strace/strace.out.1186:open("/etc/my.cnf", O_RDONLY|O_CLOEXEC) = 6
mariadb-compat-10.2.15-strace/strace.out.1186:openat(AT_FDCWD, "/etc/my.cnf.d/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 7
mariadb-compat-10.2.15-strace/strace.out.1186:stat("/etc/my.cnf.d/client.cnf", {st_mode=S_IFREG|0644, st_size=295, ...}) = 0
mariadb-compat-10.2.15-strace/strace.out.1186:open("/etc/my.cnf.d/client.cnf", O_RDONLY|O_CLOEXEC) = 7
mariadb-compat-10.2.15-strace/strace.out.1186:stat("/home/ec2-user/.my.cnf", {st_mode=S_IFREG|0664, st_size=117, ...}) = 0
mariadb-compat-10.2.15-strace/strace.out.1186:open("/home/ec2-user/.my.cnf", O_RDONLY|O_CLOEXEC) = 6
[ec2-user@ip-172-30-0-136 ~]$ grep "pem" mariadb-compat-10.2.15-strace/*
[ec2-user@ip-172-30-0-136 ~]$ sudo rpm -qa | grep -i maria
mariadb-5.5.56-2.el7.x86_64
MariaDB-compat-10.2.15-1.el7.centos.x86_64
MariaDB-common-10.2.15-1.el7.centos.x86_64

Comment by Vladislav Vaintroub [ 2018-06-07 ]

please open another bug against Connector/C then.

Comment by Geoff Montee (Inactive) [ 2018-07-09 ]

georg said on CONC-340 that libmysqlclient.so.18 from 10.2's MariaDB-compat package is not provided by MariaDB Connector/C. So where does this library come from? Is it built from 10.2's libmysqlclient, or is it actually built from some previous version of the server's libmysqlclient, or something else?

Comment by Elena Stepanova [ 2018-07-09 ]

libmysqlclient.so.18 is re-packaged into compat from mariadb-shared-10.1-kvm-rpm-centos73-amd64.rpm and alike.

Comment by Geoff Montee (Inactive) [ 2018-07-09 ]

So if libmysqlclient.so.18 from 10.2's MariaDB-compat package on RHEL 7 is repackaged from mariadb-shared-10.1-kvm-rpm-centos73-amd64.rpm, then it sounds like that means that this 10.2 package will eventually inherit this fix from 10.1 in a future 10.2 release. Is that correct?

Comment by Elena Stepanova [ 2018-07-09 ]

serg or dbart might be better people to answer this, I don't know how often these 10.1 packages, which are used for producing compat, are updated, if ever.

Comment by Daniel Bartholomew [ 2018-07-09 ]

I've updated the 10.1-shared packages we use for creating the 10.2 & 10.3 compat to the ones from 10.1.34. They're supposed to be updated with every 10.1 release, but it looks like that step got missed for the past few releases.

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