Fix failure on Fedora 27

[mscherer]

For a reason I didn't found yet, the parser of the python-mysql module
is less forgiving on Fedora than on EL7. And so spaces tend to confuse him,
resulting in "Access denied for user 'root'@'localhost' (using password: NO)"

[duck-rh]

First MariaDB 10.1.26 supports such spaces, and this seems very very weird because this has always been supported in the past. So you can use this patch locally in case of urgency but I'm against merging until we understand better what's going on.

[mscherer]

It is not mariadb or mysql issue, that's python module as I said in the commit message. For python 3 support, Fedora switched to a fork: https://github.com/PyMySQL/mysqlclient-python

There is clearly a bug when using that module on Fedora:

If I use:

user= root2

the error message say:

Access denied for user 'oot2'@'localhost' (using password: YES)")

If I use:

user = root2

The user part is ignored. And so it connect as root. The only valid syntax is "user=root". The parser just stopped stripping whitespace for whatever reason.

To test, I do have a trivial reproducer based on the ansible module:

import MySQLdb
config = {}
config['read_default_file'] = '/root/.my.cnf'
db_connection = MySQLdb.connect(**config)

I did spent my afternoon staring at gdb, python code, assembler and C, and my conclusion is that there is a problem somewhere down the line in the binary.

There is a function to parse the file, used by the python module _mariadb_read_options_from_file, in ./libmariadb/libmariadb/ma_default.c on https://github.com/MariaDB/mariadb-connector-c/blob/master/libmariadb/ma_default.c

And there is search_default_file_with_ext, in mysys/my_default.c too, that does a similar task, but with a slightly different parser, on https://github.com/MariaDB/server/blob/10.3/mysys/my_default.c

And... there is a bug in _mariadb_read_options_from_file. I am not sure what or how, but I suspect either that I misunderstood the code, or the optimisation are doing something funky, and there is some strange variable aliasing going on (at least, that's my impression when doing gdb, I didn't felt like I would do a 2nd dissambler session, or at least, not with gdb). I do exclude a bad compile, since even the latest build failed in the same way. I do exclude a recent change, since the code didn't seems to change much.

So I am trying to verify my theory by rebuilding with less agressive optimisation. (e.g, O0 rather than O2). But maybe I missed something obvious in the C code as well.

[mscherer]

I opened a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1536229

[duck-rh]

read too fast, sorry