Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5(EOL), 10.0(EOL), 10.1(EOL)
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.
Attachments
Issue Links
- is caused by
-
-
- Closed
-
- relates to
-
-
- Closed
-