executor, privileges: fix infoschema.user_privileges privilege requirements

[morgo]

What problem does this PR solve?

Issue Number: #26069

Problem Summary:

The infoschema table showed the same results for everyone. That is not expected results. It is supposed to depend on the user's credentials.

What is changed and how it works?

What's Changed:

Accessing information_schema.user_privileges will now requires the SELECT privilege on mysql.user in order to show other user's privileges.

Related changes

• Need to cherry-pick to the release branch

Check List

Tests

• Unit test

Side effects

• Breaking backward compatibility (for security reasons)

Release note

• Accessing information_schema.user_privileges will now requires the SELECT privilege on mysql.user in order to show other user's privileges.

[djshow832]

I tried it on MySQL, but why can I only see myself even if I have the select privilege on mysql.user?

mysql -h127.1 -P3306 -uroot
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 32
Server version: 8.0.25 Homebrew

Copyright (c) 2000, 2021, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> grant select on mysql.user to 'test_user'@'localhost';
Query OK, 0 rows affected (0.01 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.01 sec)

mysql> exit
Bye

mysql -h127.1 -P3306 -utest_user
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 33
Server version: 8.0.25 Homebrew

Copyright (c) 2000, 2021, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select * from information_schema.user_privileges;
+-------------------------+---------------+----------------+--------------+
| GRANTEE                 | TABLE_CATALOG | PRIVILEGE_TYPE | IS_GRANTABLE |
+-------------------------+---------------+----------------+--------------+
| 'test_user'@'localhost' | def           | USAGE          | NO           |
+-------------------------+---------------+----------------+--------------+
1 row in set (0.00 sec)

[morgo]

@djshow832 can you paste the output of SHOW CREATE USER test_user?

MySQL expands 127.0.0.1 to localhost, but in your example you have 127.1 and a grant to 'test_user'@'localhost';. But the grant would have failed if the user didn't exist as @localhost too.

I think it might be because I check for a match against ctx.GetSessionVars().User.Hostname and not ctx.GetSessionVars().User.AuthHostname if it is specified.

[djshow832]

mysql -hlocalhost -P3306 -utest_user
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 37
Server version: 8.0.25 Homebrew

Copyright (c) 2000, 2021, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select * from information_schema.user_privileges;
+-------------------------+---------------+----------------+--------------+
| GRANTEE                 | TABLE_CATALOG | PRIVILEGE_TYPE | IS_GRANTABLE |
+-------------------------+---------------+----------------+--------------+
| 'test_user'@'localhost' | def           | USAGE          | NO           |
+-------------------------+---------------+----------------+--------------+
1 row in set (0.00 sec)

mysql> select * from mysql.user where user='root' limit 1\G
*************************** 1. row ***************************
                    Host: 127.0.0.1
                    User: root
             Select_priv: Y
             Insert_priv: Y
             Update_priv: Y
             Delete_priv: Y
             Create_priv: Y
               Drop_priv: Y
             Reload_priv: Y
           Shutdown_priv: Y
            Process_priv: Y
               File_priv: Y
              Grant_priv: Y
         References_priv: Y
              Index_priv: Y
              Alter_priv: Y
            Show_db_priv: Y
              Super_priv: Y
   Create_tmp_table_priv: Y
        Lock_tables_priv: Y
            Execute_priv: Y
         Repl_slave_priv: Y
        Repl_client_priv: Y
        Create_view_priv: Y
          Show_view_priv: Y
     Create_routine_priv: Y
      Alter_routine_priv: Y
        Create_user_priv: Y
              Event_priv: Y
            Trigger_priv: Y
  Create_tablespace_priv: Y
                ssl_type:
              ssl_cipher: NULL
             x509_issuer: NULL
            x509_subject: NULL
           max_questions: 0
             max_updates: 0
         max_connections: 0
    max_user_connections: 0
                  plugin: caching_sha2_password
   authentication_string:
        password_expired: N
   password_last_changed: 2020-03-27 16:27:34
       password_lifetime: NULL
          account_locked: N
        Create_role_priv: Y
          Drop_role_priv: Y
  Password_reuse_history: NULL
     Password_reuse_time: NULL
Password_require_current: NULL
         User_attributes: NULL
1 row in set (0.00 sec)

[AilinKid]

same to Ming, mysql -h127.0.0.1 -P3306 -umy -p seem whether granting the SELECT or not, the user 'my' here can only see themselves in MySQL8

[morgo]

same to Ming, mysql -h127.0.0.1 -P3306 -umy -p seem whether granting the SELECT or not, the user 'my' here can only see themselves in MySQL8

OK, I've confirmed it is a bug. It requires SELECT, but on mysql.* not mysql.user. This makes sense, there are over privilege tables that need to be read in order to create a full dump of privileges.

[morgo]

@AilinKid @djshow832 This has been addressed in 2522c40

[AilinKid]

LGTM

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• AilinKid
• djshow832

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[AilinKid]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: 0da4dcf

[ti-srebot]

cherry pick to release-4.0 in PR #26309

[ti-srebot]

cherry pick to release-5.0 in PR #26310

[ti-srebot]

cherry pick to release-5.1 in PR #26311