Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-18290

Users identified via ed25519 are broken after upgrade to 10.4

Details

    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)
      

      Attachments

        Issue Links

          Activity

            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.

            serg Sergei Golubchik added a comment - 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.

            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.

            elenst Elena Stepanova added a comment - 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.

            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.

            serg Sergei Golubchik added a comment - 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.
            elenst Elena Stepanova added a comment - - edited

            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.

            elenst Elena Stepanova added a comment - - edited 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.

            People

              serg Sergei Golubchik
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.