[Maria-discuss] SHOW GRANTS change?
Hi all, I’ve noticed that MariaDB 10.0.14 shows an IDENTIFIED BY PASSWORD .. section in SHOW GRANTS, but 10.0.17 doesn’t show the password. I can’t find anything to this effect in the changelog; was this an intended change, or is it a bug? The MariaDB docs show SHOW GRANTS behaving without the password dump. Thank you! -FG
Can't confirm that the password does not show up on 10.0.17. This works as described below. Any chance that you were executing SHOW GRANTS on a user without password? Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 10 Server version: 10.0.17-MariaDB MariaDB Server Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> show grants for bkp@'localhost'\G *************************** 1. row *************************** Grants for bkp@localhost: GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'bkp'@'localhost' IDENTIFIED BY PASSWORD '*77863EC97510887DF16C59D8F7B8E31A0C584C7D' 2015-04-03 0:09 GMT+02:00 Felipe Gasper <felipe@felipegasper.com>:
Hi all,
I’ve noticed that MariaDB 10.0.14 shows an IDENTIFIED BY PASSWORD .. section in SHOW GRANTS, but 10.0.17 doesn’t show the password.
I can’t find anything to this effect in the changelog; was this an intended change, or is it a bug?
The MariaDB docs show SHOW GRANTS behaving without the password dump.
Thank you!
-FG
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Dear Guillaume, This is what I see: ---------------- MariaDB [(none)]> select host, password from mysql.user where user='dbguy'; +-----------+-------------------------------------------+ | host | password | +-----------+-------------------------------------------+ | localhost | *3D4FD9A495C3E81883E1A42AD351871F74F7CAA9 | +-----------+-------------------------------------------+ 1 row in set (0.00 sec) MariaDB [(none)]> show grants for 'dbguy'@'localhost'; +----------------------------------------------------------------+ | Grants for dbguy@localhost | +----------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'dbguy'@'localhost' | | GRANT ALL PRIVILEGES ON `dbguy\_goal`.* TO 'dbguy'@'localhost' | +----------------------------------------------------------------+ 2 rows in set (0.00 sec) MariaDB [(none)]> select user(); +----------------+ | user() | +----------------+ | root@localhost | +----------------+ 1 row in set (0.00 sec) --------------- That hash is the hash of the string '234wer'. There does seem to be a bug here … ? -FG On 3 Apr 2015 2:42 AM, Guillaume Lefranc wrote:
Can't confirm that the password does not show up on 10.0.17. This works as described below. Any chance that you were executing SHOW GRANTS on a user without password?
Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 10 Server version: 10.0.17-MariaDB MariaDB Server
Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show grants for bkp@'localhost'\G *************************** 1. row *************************** Grants for bkp@localhost: GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'bkp'@'localhost' IDENTIFIED BY PASSWORD '*77863EC97510887DF16C59D8F7B8E31A0C584C7D'
2015-04-03 0:09 GMT+02:00 Felipe Gasper <felipe@felipegasper.com <mailto:felipe@felipegasper.com>>:
Hi all,
I’ve noticed that MariaDB 10.0.14 shows an IDENTIFIED BY PASSWORD .. section in SHOW GRANTS, but 10.0.17 doesn’t show the password.
I can’t find anything to this effect in the changelog; was this an intended change, or is it a bug?
The MariaDB docs show SHOW GRANTS behaving without the password dump.
Thank you!
-FG
_________________________________________________ Mailing list: https://launchpad.net/~maria-__discuss <https://launchpad.net/~maria-discuss> Post to : maria-discuss@lists.launchpad.__net <mailto:maria-discuss@lists.launchpad.net> Unsubscribe : https://launchpad.net/~maria-__discuss <https://launchpad.net/~maria-discuss> More help : https://help.launchpad.net/__ListHelp <https://help.launchpad.net/ListHelp>
Note: I believe “dbguy” came from a My5.6 -> Ma10.0 upgrade. Is it possible that something in MariaDB isn’t reading MySQL stuff correctly? -FG On 13 Apr 2015 2:14 PM, Felipe Gasper wrote:
Dear Guillaume,
This is what I see:
---------------- MariaDB [(none)]> select host, password from mysql.user where user='dbguy'; +-----------+-------------------------------------------+ | host | password | +-----------+-------------------------------------------+ | localhost | *3D4FD9A495C3E81883E1A42AD351871F74F7CAA9 | +-----------+-------------------------------------------+ 1 row in set (0.00 sec)
MariaDB [(none)]> show grants for 'dbguy'@'localhost'; +----------------------------------------------------------------+ | Grants for dbguy@localhost | +----------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'dbguy'@'localhost' | | GRANT ALL PRIVILEGES ON `dbguy\_goal`.* TO 'dbguy'@'localhost' | +----------------------------------------------------------------+ 2 rows in set (0.00 sec)
MariaDB [(none)]> select user(); +----------------+ | user() | +----------------+ | root@localhost | +----------------+ 1 row in set (0.00 sec) ---------------
That hash is the hash of the string '234wer'.
There does seem to be a bug here … ?
-FG
On 3 Apr 2015 2:42 AM, Guillaume Lefranc wrote:
Can't confirm that the password does not show up on 10.0.17. This works as described below. Any chance that you were executing SHOW GRANTS on a user without password?
Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 10 Server version: 10.0.17-MariaDB MariaDB Server
Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show grants for bkp@'localhost'\G *************************** 1. row *************************** Grants for bkp@localhost: GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'bkp'@'localhost' IDENTIFIED BY PASSWORD '*77863EC97510887DF16C59D8F7B8E31A0C584C7D'
2015-04-03 0:09 GMT+02:00 Felipe Gasper <felipe@felipegasper.com <mailto:felipe@felipegasper.com>>:
Hi all,
I’ve noticed that MariaDB 10.0.14 shows an IDENTIFIED BY PASSWORD .. section in SHOW GRANTS, but 10.0.17 doesn’t show the password.
I can’t find anything to this effect in the changelog; was this an intended change, or is it a bug?
The MariaDB docs show SHOW GRANTS behaving without the password dump.
Thank you!
-FG
_________________________________________________ Mailing list: https://launchpad.net/~maria-__discuss <https://launchpad.net/~maria-discuss> Post to : maria-discuss@lists.launchpad.__net <mailto:maria-discuss@lists.launchpad.net> Unsubscribe : https://launchpad.net/~maria-__discuss <https://launchpad.net/~maria-discuss> More help : https://help.launchpad.net/__ListHelp <https://help.launchpad.net/ListHelp>
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Hi, Felipe! On Apr 13, Felipe Gasper wrote:
Note: I believe “dbguy” came from a My5.6 -> Ma10.0 upgrade.
Is it possible that something in MariaDB isn’t reading MySQL stuff correctly?
Could be. There was one issue in the way MySQL started confusing a password and the authentication string for plugins. Could you show the complete line for that user? select * from mysql.user where user='dbguy' \G Thanks! Regards, Sergei
-FG
On 13 Apr 2015 2:14 PM, Felipe Gasper wrote:
Dear Guillaume,
This is what I see:
---------------- MariaDB [(none)]> select host, password from mysql.user where user='dbguy'; +-----------+-------------------------------------------+ | host | password | +-----------+-------------------------------------------+ | localhost | *3D4FD9A495C3E81883E1A42AD351871F74F7CAA9 | +-----------+-------------------------------------------+ 1 row in set (0.00 sec)
MariaDB [(none)]> show grants for 'dbguy'@'localhost'; +----------------------------------------------------------------+ | Grants for dbguy@localhost | +----------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'dbguy'@'localhost' | | GRANT ALL PRIVILEGES ON `dbguy\_goal`.* TO 'dbguy'@'localhost' | +----------------------------------------------------------------+ 2 rows in set (0.00 sec)
MariaDB [(none)]> select user(); +----------------+ | user() | +----------------+ | root@localhost | +----------------+ 1 row in set (0.00 sec) ---------------
That hash is the hash of the string '234wer'.
There does seem to be a bug here … ?
-FG
Hi Sergei! Thanks for your quick reply! Here is the output of that command: ====================== MariaDB [(none)]> select * from mysql.user where user='dbguy' \G *************************** 1. row *************************** Host: localhost User: dbguy Password: *3D4FD9A495C3E81883E1A42AD351871F74F7CAA9 Select_priv: N Insert_priv: N Update_priv: N Delete_priv: N Create_priv: N Drop_priv: N Reload_priv: N Shutdown_priv: N Process_priv: N File_priv: N Grant_priv: N References_priv: N Index_priv: N Alter_priv: N Show_db_priv: N Super_priv: N Create_tmp_table_priv: N Lock_tables_priv: N Execute_priv: N Repl_slave_priv: N Repl_client_priv: N Create_view_priv: N Show_view_priv: N Create_routine_priv: N Alter_routine_priv: N Create_user_priv: N Event_priv: N Trigger_priv: N Create_tablespace_priv: N ssl_type: ssl_cipher: x509_issuer: x509_subject: max_questions: 0 max_updates: 0 max_connections: 0 max_user_connections: 0 plugin: mysql_native_password authentication_string: password_expired: N is_role: N 1 row in set (0.00 sec) ================== Also, here is the output for the other user, the one that SHOW GRANTS does show as having a password: ================== MariaDB [(none)]> select * from mysql.user where user='newguy' and host='localhost' \G *************************** 1. row *************************** Host: localhost User: newguy Password: *3D4FD9A495C3E81883E1A42AD351871F74F7CAA9 Select_priv: N Insert_priv: N Update_priv: N Delete_priv: N Create_priv: N Drop_priv: N Reload_priv: N Shutdown_priv: N Process_priv: N File_priv: N Grant_priv: N References_priv: N Index_priv: N Alter_priv: N Show_db_priv: N Super_priv: N Create_tmp_table_priv: N Lock_tables_priv: N Execute_priv: N Repl_slave_priv: N Repl_client_priv: N Create_view_priv: N Show_view_priv: N Create_routine_priv: N Alter_routine_priv: N Create_user_priv: N Event_priv: N Trigger_priv: N Create_tablespace_priv: N ssl_type: ssl_cipher: x509_issuer: x509_subject: max_questions: 0 max_updates: 0 max_connections: 0 max_user_connections: 0 plugin: authentication_string: password_expired: N is_role: N ================== I see that the “plugin” is different … is that maybe a culprit? -FG On 13 Apr 2015 2:43 PM, Sergei Golubchik wrote:
Hi, Felipe!
On Apr 13, Felipe Gasper wrote:
Note: I believe “dbguy” came from a My5.6 -> Ma10.0 upgrade.
Is it possible that something in MariaDB isn’t reading MySQL stuff correctly?
Could be. There was one issue in the way MySQL started confusing a password and the authentication string for plugins.
Could you show the complete line for that user? select * from mysql.user where user='dbguy' \G
Thanks!
Regards, Sergei
-FG
On 13 Apr 2015 2:14 PM, Felipe Gasper wrote:
Dear Guillaume,
This is what I see:
---------------- MariaDB [(none)]> select host, password from mysql.user where user='dbguy'; +-----------+-------------------------------------------+ | host | password | +-----------+-------------------------------------------+ | localhost | *3D4FD9A495C3E81883E1A42AD351871F74F7CAA9 | +-----------+-------------------------------------------+ 1 row in set (0.00 sec)
MariaDB [(none)]> show grants for 'dbguy'@'localhost'; +----------------------------------------------------------------+ | Grants for dbguy@localhost | +----------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'dbguy'@'localhost' | | GRANT ALL PRIVILEGES ON `dbguy\_goal`.* TO 'dbguy'@'localhost' | +----------------------------------------------------------------+ 2 rows in set (0.00 sec)
MariaDB [(none)]> select user(); +----------------+ | user() | +----------------+ | root@localhost | +----------------+ 1 row in set (0.00 sec) ---------------
That hash is the hash of the string '234wer'.
There does seem to be a bug here … ?
-FG
Actually, after I did: update mysql.user set plugin='mysql_native_password' where user='newguy' … it did NOT fix the SHOW GRANTS issue. “SHOW GRANTS FOR 'newguy'@'localhost'” still shows a password, whereas “SHOW GRANTS FOR 'dbguy'@'localhost'” does not. -FG On 13 Apr 2015 2:49 PM, Felipe Gasper wrote:
Hi Sergei!
Thanks for your quick reply! Here is the output of that command:
====================== MariaDB [(none)]> select * from mysql.user where user='dbguy' \G *************************** 1. row *************************** Host: localhost User: dbguy Password: *3D4FD9A495C3E81883E1A42AD351871F74F7CAA9 Select_priv: N Insert_priv: N Update_priv: N Delete_priv: N Create_priv: N Drop_priv: N Reload_priv: N Shutdown_priv: N Process_priv: N File_priv: N Grant_priv: N References_priv: N Index_priv: N Alter_priv: N Show_db_priv: N Super_priv: N Create_tmp_table_priv: N Lock_tables_priv: N Execute_priv: N Repl_slave_priv: N Repl_client_priv: N Create_view_priv: N Show_view_priv: N Create_routine_priv: N Alter_routine_priv: N Create_user_priv: N Event_priv: N Trigger_priv: N Create_tablespace_priv: N ssl_type: ssl_cipher: x509_issuer: x509_subject: max_questions: 0 max_updates: 0 max_connections: 0 max_user_connections: 0 plugin: mysql_native_password authentication_string: password_expired: N is_role: N 1 row in set (0.00 sec) ==================
Also, here is the output for the other user, the one that SHOW GRANTS does show as having a password:
================== MariaDB [(none)]> select * from mysql.user where user='newguy' and host='localhost' \G *************************** 1. row *************************** Host: localhost User: newguy Password: *3D4FD9A495C3E81883E1A42AD351871F74F7CAA9 Select_priv: N Insert_priv: N Update_priv: N Delete_priv: N Create_priv: N Drop_priv: N Reload_priv: N Shutdown_priv: N Process_priv: N File_priv: N Grant_priv: N References_priv: N Index_priv: N Alter_priv: N Show_db_priv: N Super_priv: N Create_tmp_table_priv: N Lock_tables_priv: N Execute_priv: N Repl_slave_priv: N Repl_client_priv: N Create_view_priv: N Show_view_priv: N Create_routine_priv: N Alter_routine_priv: N Create_user_priv: N Event_priv: N Trigger_priv: N Create_tablespace_priv: N ssl_type: ssl_cipher: x509_issuer: x509_subject: max_questions: 0 max_updates: 0 max_connections: 0 max_user_connections: 0 plugin: authentication_string: password_expired: N is_role: N ==================
I see that the “plugin” is different … is that maybe a culprit?
-FG
On 13 Apr 2015 2:43 PM, Sergei Golubchik wrote:
Hi, Felipe!
On Apr 13, Felipe Gasper wrote:
Note: I believe “dbguy” came from a My5.6 -> Ma10.0 upgrade.
Is it possible that something in MariaDB isn’t reading MySQL stuff correctly?
Could be. There was one issue in the way MySQL started confusing a password and the authentication string for plugins.
Could you show the complete line for that user? select * from mysql.user where user='dbguy' \G
Thanks!
Regards, Sergei
-FG
On 13 Apr 2015 2:14 PM, Felipe Gasper wrote:
Dear Guillaume,
This is what I see:
---------------- MariaDB [(none)]> select host, password from mysql.user where user='dbguy'; +-----------+-------------------------------------------+ | host | password | +-----------+-------------------------------------------+ | localhost | *3D4FD9A495C3E81883E1A42AD351871F74F7CAA9 | +-----------+-------------------------------------------+ 1 row in set (0.00 sec)
MariaDB [(none)]> show grants for 'dbguy'@'localhost'; +----------------------------------------------------------------+ | Grants for dbguy@localhost | +----------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'dbguy'@'localhost' | | GRANT ALL PRIVILEGES ON `dbguy\_goal`.* TO 'dbguy'@'localhost' | +----------------------------------------------------------------+ 2 rows in set (0.00 sec)
MariaDB [(none)]> select user(); +----------------+ | user() | +----------------+ | root@localhost | +----------------+ 1 row in set (0.00 sec) ---------------
That hash is the hash of the string '234wer'.
There does seem to be a bug here … ?
-FG
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Actually (redux), … once I did a FLUSH PRIVILEGES, this behaved as expected. This seems like a pretty big “gotcha” of MySQL -> MariaDB upgrades. Should MariaDB not accept “mysql_native_password” as a value in that column? -FG On 13 Apr 2015 3:02 PM, Felipe Gasper wrote:
Actually, after I did:
update mysql.user set plugin='mysql_native_password' where user='newguy'
… it did NOT fix the SHOW GRANTS issue.
“SHOW GRANTS FOR 'newguy'@'localhost'” still shows a password, whereas “SHOW GRANTS FOR 'dbguy'@'localhost'” does not.
-FG
On 13 Apr 2015 2:49 PM, Felipe Gasper wrote:
Hi Sergei!
Thanks for your quick reply! Here is the output of that command:
====================== MariaDB [(none)]> select * from mysql.user where user='dbguy' \G *************************** 1. row *************************** Host: localhost User: dbguy Password: *3D4FD9A495C3E81883E1A42AD351871F74F7CAA9 Select_priv: N Insert_priv: N Update_priv: N Delete_priv: N Create_priv: N Drop_priv: N Reload_priv: N Shutdown_priv: N Process_priv: N File_priv: N Grant_priv: N References_priv: N Index_priv: N Alter_priv: N Show_db_priv: N Super_priv: N Create_tmp_table_priv: N Lock_tables_priv: N Execute_priv: N Repl_slave_priv: N Repl_client_priv: N Create_view_priv: N Show_view_priv: N Create_routine_priv: N Alter_routine_priv: N Create_user_priv: N Event_priv: N Trigger_priv: N Create_tablespace_priv: N ssl_type: ssl_cipher: x509_issuer: x509_subject: max_questions: 0 max_updates: 0 max_connections: 0 max_user_connections: 0 plugin: mysql_native_password authentication_string: password_expired: N is_role: N 1 row in set (0.00 sec) ==================
Also, here is the output for the other user, the one that SHOW GRANTS does show as having a password:
================== MariaDB [(none)]> select * from mysql.user where user='newguy' and host='localhost' \G *************************** 1. row *************************** Host: localhost User: newguy Password: *3D4FD9A495C3E81883E1A42AD351871F74F7CAA9 Select_priv: N Insert_priv: N Update_priv: N Delete_priv: N Create_priv: N Drop_priv: N Reload_priv: N Shutdown_priv: N Process_priv: N File_priv: N Grant_priv: N References_priv: N Index_priv: N Alter_priv: N Show_db_priv: N Super_priv: N Create_tmp_table_priv: N Lock_tables_priv: N Execute_priv: N Repl_slave_priv: N Repl_client_priv: N Create_view_priv: N Show_view_priv: N Create_routine_priv: N Alter_routine_priv: N Create_user_priv: N Event_priv: N Trigger_priv: N Create_tablespace_priv: N ssl_type: ssl_cipher: x509_issuer: x509_subject: max_questions: 0 max_updates: 0 max_connections: 0 max_user_connections: 0 plugin: authentication_string: password_expired: N is_role: N ==================
I see that the “plugin” is different … is that maybe a culprit?
-FG
On 13 Apr 2015 2:43 PM, Sergei Golubchik wrote:
Hi, Felipe!
On Apr 13, Felipe Gasper wrote:
Note: I believe “dbguy” came from a My5.6 -> Ma10.0 upgrade.
Is it possible that something in MariaDB isn’t reading MySQL stuff correctly?
Could be. There was one issue in the way MySQL started confusing a password and the authentication string for plugins.
Could you show the complete line for that user? select * from mysql.user where user='dbguy' \G
Thanks!
Regards, Sergei
-FG
On 13 Apr 2015 2:14 PM, Felipe Gasper wrote:
Dear Guillaume,
This is what I see:
---------------- MariaDB [(none)]> select host, password from mysql.user where user='dbguy'; +-----------+-------------------------------------------+ | host | password | +-----------+-------------------------------------------+ | localhost | *3D4FD9A495C3E81883E1A42AD351871F74F7CAA9 | +-----------+-------------------------------------------+ 1 row in set (0.00 sec)
MariaDB [(none)]> show grants for 'dbguy'@'localhost'; +----------------------------------------------------------------+ | Grants for dbguy@localhost | +----------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'dbguy'@'localhost' | | GRANT ALL PRIVILEGES ON `dbguy\_goal`.* TO 'dbguy'@'localhost' | +----------------------------------------------------------------+ 2 rows in set (0.00 sec)
MariaDB [(none)]> select user(); +----------------+ | user() | +----------------+ | root@localhost | +----------------+ 1 row in set (0.00 sec) ---------------
That hash is the hash of the string '234wer'.
There does seem to be a bug here … ?
-FG
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Hi, Felipe! On Apr 13, Felipe Gasper wrote:
Actually (redux),
… once I did a FLUSH PRIVILEGES, this behaved as expected.
This seems like a pretty big “gotcha” of MySQL -> MariaDB upgrades. Should MariaDB not accept “mysql_native_password” as a value in that column?
Right, that's exactly the issue I was referring to. I know about this case because I've fixed it. It's MDEV-6253 and it was fixed in 10.0.12. But ok, now I see that the bug was about the user being unable to connect. That part was fixed. But SHOW GRANTS apparently wasn't. Reported as MDEV-7985 Regards, Sergei
Hi Sergei! On 13 Apr 2015 5:34 PM, Sergei Golubchik wrote:
Should MariaDB not accept “mysql_native_password” as a value in that column?
Right, that's exactly the issue I was referring to. I know about this case because I've fixed it. It's MDEV-6253 and it was fixed in 10.0.12.
But ok, now I see that the bug was about the user being unable to connect. That part was fixed. But SHOW GRANTS apparently wasn't.
Reported as MDEV-7985
What will the “life” of this bug and its fix look like? Is there anything that could be done to help bump it along? We have code that depends on SHOW GRANTS for backups; that logic is now effectively discarding users’ passwords when, for example, an account is transferred from one server to another. As a workaround I’m going to do: UPDATE mysql.user SET plugin='' WHERE plugin='mysql_native_password'; FLUSH PRIVILEGES; Does this look like a reasonable workaround? Also, are all 10.0 releases affected, do we know? Thank you! :) -Felipe Gasper
Hi, Felipe! On Apr 14, Felipe Gasper wrote:
On 13 Apr 2015 5:34 PM, Sergei Golubchik wrote:
Should MariaDB not accept “mysql_native_password” as a value in that column?
Right, that's exactly the issue I was referring to. I know about this case because I've fixed it. It's MDEV-6253 and it was fixed in 10.0.12.
But ok, now I see that the bug was about the user being unable to connect. That part was fixed. But SHOW GRANTS apparently wasn't.
Reported as MDEV-7985
What will the “life” of this bug and its fix look like? Is there anything that could be done to help bump it along?
The bug has fixVersion 10.0, which generally means it should be fixed in the next 10.0 release (unless we'll have too many higher-priority bugs). So for now you can expect that nothing will happen to MDEV-7985 until 10.0 is the next release in our release schedule. After that you can expect this bug to be fixed. The release schedule is in Jira (I'm keeping it up to date, so I encourage people to look at it :). The current plan is to have 5.5.43 released on 2015-04-21, then 10.0.18 on 2015-04-28, then 10.1.5 on 2015-05-12. So, unless the plan changes, you can expect no activity on the bug until 2015-04-21, and then it should be closed as fixed no later than 2015-04-28. There is no need to bump the priority - it's high enough to almost guarantee a fix in 10.0.18.
As a workaround I’m going to do:
UPDATE mysql.user SET plugin='' WHERE plugin='mysql_native_password'; FLUSH PRIVILEGES;
Does this look like a reasonable workaround?
Yes. Perfectly reasonable.
Also, are all 10.0 releases affected, do we know?
I think so, yes :( Regards, Sergei
participants (3)
-
Felipe Gasper -
Guillaume Lefranc -
Sergei Golubchik