Description:
I'm not sure is this bug report or feature request. But it looks more like a bug for me.
In fact synopsis should be something like: compared passwords are not converted to same charset representation before applying password() function.
The problem is looks like this: if one adds user and providing password in one charset, and then some client sends(passes to mysql_real_connect) the same string's representation in other charset(and i won't disguise that i'm talk here about utf8 mainly), and if this representation differs from original(non-latin characters is usual reason), - client will see "access denied".
How to repeat:
In the Windows command line(to ensure it won't be utf8) run CLI and add user like
GRANT ALL ON *.* TO 'someuser'@'%' identified by 'б'; # password contains cyrillic character
Then try to connect using some linux shell(utf8) try to run smth like
mysql -h<your_dbserver_host> -u someuser -pб test
Another option could be c/odbc 5.1 DSN configuration dialog on windows. myodbc5.1 converts all login credentials to utf8. And dialog has "Test" connection button.
"Access denied" you supposed to get at this point.
Now if you do
update user set password=password(0xD0B1) where User='someuser'; # 0xD0B1 is bytes for "б" in utf8
flush privileges;
Both connections will be successful.
And one more little thing: --default-character-set doesn't come in play here from my observations.
Suggested fix:
Convert password to utf8 before saving in mysql.user and do the same during authentication process with supplied password. I'm not sure, but possibly the latter should be done on client side in c/c or in other connectors, that have own protocol implementation.
