Hi, Wlad! On Jan 08, wlad@mariadb.com wrote:
1. Space before "Value" 2. Why 0 disables blocking? max_connect_errors doesn't have a special 0 value.
Alright, I removed a special value 0 , and made 1 the minimal value, like max_connect_errors does, so it does not appear different from anything else and does not create any confusion, but let me explain the original intention, which was
1. Zero performance overhead, if the option is not used. Without special value , there will be overhead in case of invalid password - extra scanning of the acl_users array (under mutex protection).
2. No side-effects, if the option is not used. Technically, even if unlikely, if someone supplies 4294967295 of invalid passwords in a row, the account will be locked. It only takes 50 days, if connection attempt is made every millisecond. With special value account won't be blocked.
You could make 4294967295 a special value. It'll provide this zero-overhead. It won't block after 4294967295 invalid passwords, but I think it's not a big deal :)
@@ -13305,6 +13370,8 @@ bool acl_authenticate(THD *thd, uint com_change_user_pkt_len) break; case CR_AUTH_USER_CREDENTIALS: errors.m_authentication= 1; + if (thd->password && max_password_errors)
add && !mpvio->make_it_fail here (see how make_it_fail is set).
I added the condition, even if so far this condition is obsolete. mpvio->make_it_fail only produces CR_ERROR, not CR_AUTH_USER_CREDENTIALS.
No, mpvio->make_it_fail produces CR_ERROR if the authentication has otherwise succeeded. Most probably mpvio->make_it_fail will produce CR_AUTH_USER_CREDENTIALS. Because mpvio->make_it_fail means "pick some random (kind of) user from the acl_users list and try to authenticate as that user". Unless you've guessed the password of this random user, you'll get CR_AUTH_USER_CREDENTIALS. Regards, Sergei Chief Architect MariaDB and security@mariadb.org