Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
10.1.14
Description
Preamble.
mysql cli was known for "ignoring" --ssl option on its own. If someone needed to enable SSL on client side they had to specify any other ssl option, e. g. --ssl-cipher=AES128-SHA. This was fixed in MariaDB, I guess by mysql_ssl_set() setting use_ssl = TRUE unconditionally. Thus we now can use mysql --ssl with MariaDB (and maybe with latest MySQL).
Recently I discovered another difference in behavior of MariaDB's and MySQL's libmysqlclient:
If I don't call mysql_ssl_set(), but have SSL options in the configuration file, SSL gets enabled with MySQL's, but does not with MariaDB's. It feels like use_ssl = TRUE should be executed in one more place.
E. i. let's have this file:
[foo]
|
host = example.com
|
ssl-cipher=AES128-SHA
|
And do
mysql_init(NULL);
|
mysql_option(...); // Set option file and group
|
mysql_real_connect(/* all NULLs */);
|
// SSL enabled with MySQL's, disabled with MariaDB's
|
I'd expect SSL enabled if any SSL option is set.
Attachments
Issue Links
- causes
-
-
- Closed
-
- is caused by
-
MDEV-7937 Enforce SSL when --ssl client option is used
-
- Closed
-
- relates to
-
-
- Closed
-
Activity
I assume the 10.2 and 10.3 fix versions for this will be 10.2.16 and 10.3.8 based on the estimated release dates. Is that correct?
you know how it works GeoffMontee. It is pushed into version X, whenever X,Y,or Z are released, the patch is merged up, so the next 5.5, 10.0,10.1 will have it.
The "next" release is the one where last number component is incremented.
And BTW, there is no fix for 10.2 and 10.3. If the problem exist there (which I did not bother tp check) it is not the server problem anymore, but C/Cs
Yeah, I understand how the merge process works. Thanks! I just wanted to make sure I wasn't missing any important details specific to this case in case 10.2 and 10.3 were intentionally left out of "Fix Versions". It sounds like 10.2 and 10.3 were left out because of the the switch to Connector/C in 10.2 and above.
From my understanding though, libmysqlclient.so was not entirely replaced with C/C in 10.2. You can see that some of the child tasks of MDEV-9055 are still open. I think it is true that client tools like "mysql" and "mysqldump" use C/C now, but it looks like libmysqlclient.so is still built with 10.2 and many tools not built by us (such as perl's DBD::MySQL) still link to that. For example, it looks like libmysqlclient.so is included in 10.2's MariaDB-compat package on RHEL 7:
[ec2-user@ip-172-30-0-58 ~]$ rpm -q --provides MariaDB-compat
|
MariaDB-compat = 10.2.14-1.el7.centos
|
MariaDB-compat(x86-64) = 10.2.14-1.el7.centos
|
MariaDB-shared = 10.1.30-1.el7.centos
|
MariaDB-shared(x86-64) = 10.1.30-1.el7.centos
|
MySQL-shared
|
config(MariaDB-shared) = 10.1.30-1.el7.centos
|
config(mariadb-libs) = 1:10.1.30-1.el7.centos
|
config(mysql-libs) = 1:10.1.30-1.el7.centos
|
libmysqlclient.so.15()(64bit)
|
libmysqlclient.so.15(libmysqlclient_15)(64bit)
|
libmysqlclient.so.16()(64bit)
|
libmysqlclient.so.16(libmysqlclient_16)(64bit)
|
libmysqlclient.so.18()(64bit)
|
libmysqlclient.so.18()(64bit)
|
libmysqlclient.so.18(libmariadbclient_18)(64bit)
|
libmysqlclient.so.18(libmariadbclient_18)(64bit)
|
libmysqlclient.so.18(libmysqlclient_16)(64bit)
|
libmysqlclient.so.18(libmysqlclient_16)(64bit)
|
libmysqlclient.so.18(libmysqlclient_18)(64bit)
|
libmysqlclient.so.18(libmysqlclient_18)(64bit)
|
libmysqlclient_r.so.15()(64bit)
|
libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
|
libmysqlclient_r.so.16()(64bit)
|
libmysqlclient_r.so.16(libmysqlclient_16)(64bit)
|
mariadb-libs = 1:10.1.30-1.el7.centos
|
mariadb-libs(x86-64) = 1:10.1.30-1.el7.centos
|
mysql-libs = 1:10.1.30-1.el7.centos
|
mysql-libs(x86-64) = 1:10.1.30-1.el7.centos
|
mysql-shared
|
This is still the old libmysqlclient.so, not Connector/C, right? It looks like the perl DBD::MySQL package on RHEL 7 still depends on this libmysqlclient.so, rather than the libmariadb.so from MariaDB-shared:
[ec2-user@ip-172-30-0-58 ~]$ rpm -q --requires perl-DBD-MySQL
|
libc.so.6()(64bit)
|
libc.so.6(GLIBC_2.2.5)(64bit)
|
libc.so.6(GLIBC_2.3)(64bit)
|
libc.so.6(GLIBC_2.3.4)(64bit)
|
libc.so.6(GLIBC_2.4)(64bit)
|
libcrypto.so.10()(64bit)
|
libdl.so.2()(64bit)
|
libm.so.6()(64bit)
|
libmysqlclient.so.18()(64bit)
|
libmysqlclient.so.18(libmysqlclient_18)(64bit)
|
libpthread.so.0()(64bit)
|
libpthread.so.0(GLIBC_2.2.5)(64bit)
|
libssl.so.10()(64bit)
|
libz.so.1()(64bit)
|
perl >= 0:5.005
|
perl(:MODULE_COMPAT_5.16.3)
|
perl(Carp)
|
perl(DBD::mysql)
|
perl(DBI)
|
perl(DBI::Const::GetInfoType)
|
perl(DynaLoader)
|
perl(strict)
|
perl(vars)
|
rpmlib(CompressedFileNames) <= 3.0.4-1
|
rpmlib(FileDigests) <= 4.6.0-1
|
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
|
rtld(GNU_HASH)
|
rpmlib(PayloadIsXz) <= 5.2-1
|
It does look like sql-common/client.c from 10.2 has the problematic change:
If I understood the circumstances correctly, then it seems like this fix for libmysqlclient.so is not completely irrelevant for 10.2 and 10.3. I'll go ahead and assume that the fix for this issue and MDEV-16396 will be in 10.2.16 and 10.3.8, but please let me know if I misunderstood anything.
there are 3 clients in 10.2+
1)libmariadbclient, used by all command line clients, and APIs
2)another one inside the server, used by connect and federated, spider and replication
3)another one is embedded
Only 1) is very much visible, and others are obscure more or less.
So libmysqlclient.so from the MariaDB 10.2 packages actually refers to libmariadbclient (i.e. MariaDB Connector/C). Thanks, wlad.
wlad, could you please take a look?
I'm not exactly sure if it's supposed to work or not, but it does indeed work with MySQL 5.6+ (and with libmysqlclient18:amd64 5.5.49-0+deb8u1 provided by Debian), but does not work with vanilla MySQL 5.5 and with MariaDB.