Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-16396

Perl's DBD::MySQL does not read SSL settings from [client] configuration group with MariaDB libmysqlclient.so

    XMLWordPrintable

    Details

      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

            Activity

              People

              Assignee:
              wlad Vladislav Vaintroub
              Reporter:
              GeoffMontee Geoff Montee
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: