[MDEV-9389] Inconsistent auth packet sent by client Created: 2016-01-11  Updated: 2019-04-10  Resolved: 2019-04-10

Status: Closed
Project: MariaDB Server
Component/s: Protocol
Affects Version/s: 10.1.9
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Andy Salnikov Assignee: Sergei Golubchik
Resolution: Won't Fix Votes: 0
Labels: client
Environment:

Centos7, x86_64, gcc 4.8.5, mysql-proxy 0.8.2



 Description   

Sorry, this is my first time submitting a bug to mariadb, let me know if I messed it up.

We are migrating from mysql to mariadb and one piece of our system is mysql-proxy which refuses to work with mariadb client. I worked ok with mysql server/client (obviously) but we see an interesting issue with mariadb:

  • if we run mariadb server and mariadb client with mysql-proxy in between we cannot actually run, client fails immediately with the message: ERROR 1043 (08S01): Bad handshake
  • but we can run with mysql client and mariadb server (and mysql-proxy)

After some debugging I believe the reason is incorrect handling of CLIENT_CONNECT_ATTRS by mariadb client. Examining packets sent to/from proxy here I can see:

  • proxy modifies server handshake packet strips some capability flags from it, including CLIENT_CONNECT_ATTRS, so that client does not see that flag in server capabilities
  • client always sets that flag in its auth packet but it does not fill connection attributes in the packet, which I believe makes inconsistent packet
  • proxy does not modify client auth packet in any way and passes it to server which complains about that inconsistency (though without giving actual reason)

Looking at the code in sql-common/client.c I think this inconsistency happens because:

  • client always sets CLIENT_CONNECT_ATTRS flag no matter what
  • but it only fills connection attributes if server capabilities have that flag

I think correct behavior on client side should be to only set that flag if server-side flag is set. This probably applies to few other flags as well, I think mysql protocol description expects from client to only set flags which are also supported by server.

I could not find any way to workaround that client behavior without patching sources (I think proxy is very limited in what it can do with auth packets). If you can confirm that this behavior is problematic it would be nice to have it fixed eventually (sooner better than later of course).



 Comments   
Comment by Elena Stepanova [ 2016-01-12 ]

AndyS,

Which version of mysql-proxy are you using?
What is your exact command line for mysql-proxy?
Did you build MariaDB server/client from source? If so, what are your cmake/build options?
Please also provide MariaDB cnf file(s) or command-line options.

10.1.9 from the binary tarball and proxy 0.8.5 seem to work okay for me (at least they connect). There must be something else in there.

Comment by Andy Salnikov [ 2016-01-12 ]

elenst, we are running with mysql-proxy 0.8.2 for the moment, did not upgrade it for quite some time. I looked at github changelog for mysqlproxy but did not see anything relevant that would indicate improved handling of inconsistent packets. I guess I need to try 0.8.5 and see if it works better. I'll let you know as soon as I get some results.

Comment by Elena Stepanova [ 2016-01-12 ]

Indeed, I've tried 0.8.2 and got the same error. 0.8.5 works all right at the first glance. Please try and let us know.

Comment by Andy Salnikov [ 2016-01-12 ]

I have built mysqlproxy 0.8.5 and it indeed works fine with mariadb. I checked the handshake packets and it looks like new version handles all flags much better and it strips very little information from server handshake. Sorry for the noise, I should have checked new version myself, I guess I was suspicious about that flag handling in mariadb code (and I still believe it is inconsistent, so you may want to check that if you care).

Thanks for the hint and sorry for trouble again, I guess this issue can be resolved.

Comment by Elena Stepanova [ 2016-01-12 ]

serg,
Maybe you want to look at the inconsistency that AndyS describes.
I'm confirming the issue for proxy 0.8.2 (maybe some later versions, I didn't check), and reducing the priority because with the latest available proxy 0.8.5 it works all right.

Generated at Thu Feb 08 07:34:18 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.