Le 7/1/21 à 7:14 AM, Daniel Black a écrit :
It seems users are still disturbed at creating passwordless users in
mysql for mysql-check.
https://discourse.haproxy.org/t/haproxy-mysql-check-user-removal/6685

I certainly understand not wanting to implement the truly ugly
implementation that is the protocol to support multiple password
mechanisms ( mysql_native_password, mysql_caching_sha256_password
etc).

As a middle ground, would you be willing to take a haproxy patch that:
* accepts an account locked error on the client as a valid state?; and/or
* offer the CLIENT_CAN_HANDLE_EXPIRED_PASSWORDS client capability and
accept the password expired error ( 1820) as a valid state?

This would enable users to deploy a user account for MySQL and MariaDB
that is truly unusable and make the assessment to use this
functionality easier from a risk management point of view.

On the mysql/mariadb server side both of these are Notes like below:

2021-07-01T04:41:03.144498Z 4554 [Note] Your password has expired. To
log in you must change it using a client that supports expired
passwords.
2021-07-01T04:57:30.706593Z 5056 [Note] Access denied for user
'haproxy'@'10.0.2.100'. Account is locked.

This has the consequences that:
* these aren't counted as connection errors therefore reaching the
default 100 max_connect_errors isn't hit because of this.
* dropping MySQL's log_error_verbosity=2 from 3(default) will hide
these informational messages from the logs that would otherwise be
quite noisy while not hiding anything else too significant.

In the same area of code, dropping the MySQL-4.0 protocol support is
probably called for given the MySQL-5.0 was end of support in January
9, 2012 https://endoflife.software/applications/databases/mysql . 4.1
protocol is still in use.


Hi,

First of all, it is a good idea to remove support of "pre-41" option. It is not the default option anymore and I guess it is old enough to be removed. It is now on my todo list.

About the MySQL check itself and the way it works, I'm open to any suggestion. From the check point of view, your proposal seems reasonable. Of course, the actual behavior must still be supported (passwordless account). However, from the MySQL administration point of view, I don't know if it is acceptable or not. I'm not a MySQL admin and I don't know if it is acceptable or not to change the log level.

I guess that if no one has a better idea or any objections about this change, you can provide a patch.

--
Christopher Faulet

Reply via email to