[MDEV-18290] Users identified via ed25519 are broken after upgrade to 10.4 Created: 2019-01-17  Updated: 2019-01-18  Resolved: 2019-01-18

Status: Closed
Project: MariaDB Server
Component/s: Authentication and Privilege System
Affects Version/s: 10.4
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by MDEV-17950 SHOW GRANTS FOR does not work for a u... Closed

 Description   

On 10.3 or earlier versions, create a user identified via ed25519 plugin:

MariaDB [test]> install soname 'auth_ed25519';
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [test]> create user foo@localhost identified via ed25519 using 'test';
 
Query OK, 0 rows affected (0.01 sec)
 
 
 
MariaDB [test]> select user, host, password, plugin, authentication_string from mysql.user where user = 'foo' \G
 
*************************** 1. row ***************************
 
                 user: foo
 
                 host: localhost
 
             password: 
               plugin: ed25519
 
authentication_string: test
 
1 row in set (0.00 sec)

Shutdown the server, start 10.4 on the same datadir, run mysql_upgrade.

MariaDB [test]> select plugin_name, plugin_status from information_schema.plugins where plugin_name = 'ed25519';
 
+-------------+---------------+
 
| plugin_name | plugin_status |
 
+-------------+---------------+
 
| ed25519     | ACTIVE        |
 
+-------------+---------------+
 
1 row in set (0.00 sec)
 
 
 
MariaDB [test]> show grants for foo@localhost;
 
ERROR 1141 (42000): There is no such grant defined for user 'foo' on host 'localhost'
 
 
 
MariaDB [test]> select user, host, password, plugin, authentication_string from mysql.user where user = 'foo' \G
 
*************************** 1. row ***************************
 
                 User: foo
 
                 Host: localhost
 
             Password: 
               plugin: ed25519
 
authentication_string: test
 
1 row in set (0.01 sec)

It appears that the rules have become stricter, and now authentication_string must be the hashed password. Unfortunately, it's not that simple to unset/update the password. I did it eventually this way:

MariaDB [test]> update mysql.global_priv set Priv = '{"access":0,"ssl_type":0,"ssl_cipher":"","x509_issuer":"","x509_subject":"","max_questions":0,"max_updates":0,"max_connections":0,"max_user_connections":0,"max_statement_time":0.000000,"plugin":"ed25519","authentication_string":"","default_role":"","is_role":false}' where user = 'foo';
 
Query OK, 1 row affected (0.01 sec)
 
Rows matched: 1  Changed: 1  Warnings: 0
 
 
 
MariaDB [test]> flush privileges;
 
Query OK, 0 rows affected (0.00 sec)

Now it works:

MariaDB [test]> show grants for foo@localhost;
 
+----------------------------------------------------------------+
 
| Grants for foo@localhost                                       |
 
+----------------------------------------------------------------+
 
| GRANT USAGE ON *.* TO 'foo'@'localhost' IDENTIFIED VIA ed25519 |
 
+----------------------------------------------------------------+
 
1 row in set (0.00 sec)



 Comments   
Comment by Sergei Golubchik [ 2019-01-18 ]

Same as MDEV-17950. Hash is invalid, so the user is skipped. In earlier versions it wasn't skipped, but the authentication, obviously, didn't work.

When MDEV-17950 fix will be pushed, 10.4 will behave as before — the user will exist, but authentication won't work until the password hash will be updated to something valid.

Comment by Elena Stepanova [ 2019-01-18 ]

I filed it separately on purpose, because I don't think that MDEV-17950 alone sufficiently solves it.

This issue signifies an exemplary broken upgrade.
The user was valid before, it became invalid not due to a 3rd-party change in authentication, not due to a previous user error or a wrong way they run upgrade, but only because we've decided to store data in a different way than before, making the new version incompatible with the previous one.

I don't know how many users out there actually use ed25519, but assuming that the amount is not negligible, it's not viable to make them manually update all the passwords. I suppose it might also break the upgrade itself, if the superuser is identified via ed25519.

At the very least we could re-code the passwords for ed25519 accounts during mysql_upgrade. It won't solve the hypothetical problem with upgrade, though.

Comment by Sergei Golubchik [ 2019-01-18 ]

You miss the point. It's not about json or a a new storage format. This issue was caused by exactly the same reason as MDEV-17950, that is by MDEV-12321.

Note that "test" is not a valid hash for ed25519 and 

create user foo@localhost identified via ed25519 using 'test';

does not mean that the user can log in with the password "test". It means that the user can not log in at all, because no password will correspond to the hash "test". But 10.3 did not do any hash validation for ed25519 until you actually try to log in. It only validated hashes for built-in plugins.

After MDEV-12321 all password hashes are validated, and if a validation fails the user is skipped, not loaded. A validation can fail, because the plugin isn't loaded, like in MDEV-17950, or because the hash itself is invalid, like in this issue.

The fix for MDEV-17950 delays hash validation until the first authentication attempt. So users with invalid hashes will be loaded and show grants will work.

Comment by Elena Stepanova [ 2019-01-18 ]

I see, thanks. Sorry, I was wrong, I lost track of what was allowed where, thought if 10.3 allowed to create a user USING <plain password>, it was actually working afterwards.

Generated at Thu Feb 08 08:42:58 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.