Sergei Golubchik added a comment - 2016-04-17 20:51 There is no need to specify the old/native plugin at all, and neither to use auth_string for them, ever. But a user can do that still, a plugin is just a plugin and can be specified using the standard plugin auth syntax. And when a plugin is specified, MariaDB assumes that the password is in auth_string (MariaDB doesn't even know it's a password, it's simply opaque plugin specific authentication data). To fix the “ FLUSH PRIVILEGES oddity”, I can make SET PASSWORD to have no effect both before and after the FLUSH . If that's what you mean?

Elena Stepanova added a comment - 2016-04-17 21:35 - edited To fix the “FLUSH PRIVILEGES oddity”, I can make SET PASSWORD to have no effect both before and after the FLUSH. If that's what you mean? Yes, that's what I meant. I don't expect we'll break any user setups this way, because it's hard to imagine somebody seriously relies on the password working only till server restart, or even less. But if you sense any hidden danger at all in this change, please ignore it, it's not so important, just confusing. For the other part, need vs can , yes, I wish a user actually couldn't do that, because it doesn't really make sense and doesn't add any flexibility, only room for human errors. But for example in 10.1, even though a user can say create user ... identified with 'mysql_native_password' (or mysql_old_password ), the server does not care about it at all, does not put it into the {mysql.user.plugin}} field, hence no further problem (although, of course, it is in itself strange that the server ignores the instruction without as much as a warning). And of course, a user can always update mysql.user table, but I'm much less worried about this scenario, as long as we document what is taken from where in which case (when password is used, when authentication_string is used, etc.) – and we should get it documented anyway unless it's already somewhere in the KB; then we can claim that users who want to tamper with such an important table, at the very least should read the documentation.

Sergei Golubchik added a comment - 2016-04-18 14:44 Not quite, 10.1 does not ignore the instruction. Privilege tables are ambiguous, there are two ways to specify the password and native/old plugin: with the password or with the plugin/auth_str pair. 10.1 normalizes the input to always use the same variant, while 5.5 and 10.0 did not do that. I'm now fixing 5.5 to do the same. SET PASSWORD will clear plugin/auth_str fields if the plugin is native/old.

Elena Stepanova added a comment - 2016-04-18 15:06 That's not what I mean by "ignore", though. MariaDB [test]> select @@version; + -----------------------+ | @@version | + -----------------------+ | 10.1.13-MariaDB-debug | + -----------------------+ 1 row in set (0.00 sec)   MariaDB [test]> create user 'foo' @ 'localhost' identified with 'mysql_old_password' ; Query OK, 0 rows affected (0.00 sec)   MariaDB [test]> select user , host, password , plugin, authentication_string from mysql. user where user = 'foo' ; + ------+-----------+----------+--------+-----------------------+ | user | host | password | plugin | authentication_string | + ------+-----------+----------+--------+-----------------------+ | foo | localhost | | | | + ------+-----------+----------+--------+-----------------------+ 1 row in set (0.00 sec) MariaDB [test]> select @@version; + -----------------------+ | @@version | + -----------------------+ | 10.0.24-MariaDB-debug | + -----------------------+ 1 row in set (0.00 sec)   MariaDB [test]> create user 'foo' @ 'localhost' identified with 'mysql_old_password' ; Query OK, 0 rows affected (0.00 sec)   MariaDB [test]> select user , host, password , plugin, authentication_string from mysql. user where user = 'foo' ; + ------+-----------+----------+--------------------+-----------------------+ | user | host | password | plugin | authentication_string | + ------+-----------+----------+--------------------+-----------------------+ | foo | localhost | | mysql_old_password | | + ------+-----------+----------+--------------------+-----------------------+ 1 row in set (0.00 sec) It doesn't matter whether we provide the USING <password hash> clause with the command or not – 10.1 keeps plugin field empty, while 10.0 puts a value in it.

George L added a comment - 2016-12-19 07:31 - edited is this still a problem in mariadb 10.1.19 and 10.1.20 https://community.centminmod.com/posts/41792/ ?