MySQL Bugs: #116953: Users without any privileges can access information_schema.INNODB_FIELDS to retrieve column names of other users' tables

Bug #116953	Users without any privileges can access information_schema.INNODB_FIELDS to retrieve column names of other users' tables
Submitted:	11 Dec 2024 16:46	Modified:	11 Dec 2024 19:12
Reporter:	Jingzhou Fu	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Information schema	Severity:	S3 (Non-critical)
Version:	8.0	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Users without any privileges can also access information_schema.INNODB_FIELDS, which can be used to retrieve column names of other users' tables.

The documentation said, "You must have the PROCESS privilege to query this table. ". However, it seems like non-privileged users can also access this table and retrieve some information.

How to repeat:
The Proof of Concept (PoC) on docker image mysql:9.1.0 :

```
bash$ docker run -e MYSQL_ALLOW_EMPTY_PASSWORD=1 -p 3306:3306 -itd --name some-mysql mysql:9.1.0
bash$ docker exec -it some-mysql mysql -uroot

-- Execute the following SQL commands with the root user
mysql> USE mysql;
  CREATE TABLE tbl1 (col1234567890 INT); -- Create some normal tables
  CREATE INDEX idx1 ON tbl1 (col1234567890);

  CREATE USER foo; -- Create a empty user
  QUIT;

-- Login with the user `foo`
bash$ docker exec -it some-mysql mysql -ufoo

-- Unexpected result: the non-privileged user can see the column name
mysql> SELECT * FROM information_schema.INNODB_FIELDS;
+--------------------+--------------------+-----+
| INDEX_ID           | NAME               | POS |
+--------------------+--------------------+-----+
...
| 0x313539           | col1234567890      |   0 |
+--------------------+--------------------+-----+

Suggested fix:
Fix the permission check of information_schema.INNODB_FIELDS.

Hi Mr. Fu,

Thank you for your bug report.

However, in order to repeat what you observed, we need to know the exact set of privileges for the user foo.

Without that info, we can not repeat what you are reporting.

Also, have you discovered whether the same fault occurs with 8.0 and 8.4 ???

Hi Mr. Fu,

Last, but not least, can you let us know the exact chapter which explains what privileges are required for the access to the I_S.innodb_fields ????

Thanks in advance.

I do not grant any permission to the user `foo`. I will provide a single bash script to reproduce it, wait a minute.

The official website of MySQL provide the information about the PROCESS privilege needed by INNODB_FIELDS (around the word "Notes"): https://dev.mysql.com/doc/refman/9.1/en/information-schema-innodb-fields-table.html

Here is a single bash script to reproduce it with docker image mysql:9.1.0

```bash
#!/bin/bash
docker container rm some-mysql -f
docker run -e MYSQL_ALLOW_EMPTY_PASSWORD=1 -p 3306:3306 -itd --name some-mysql mysql:9.1.0
echo "Waiting the server start...";
sleep 15    # wait for the MySQL server to start...

docker exec -it some-mysql mysql -uroot -e "USE mysql; CREATE TABLE tbl1 (col1234567890 INT); CREATE INDEX idx1 ON tbl1 (col1234567890);"
docker exec -it some-mysql mysql -uroot -e "CREATE USER foo;"

# Unexpected result: the non-privileged user can see the column name
docker exec -it some-mysql mysql -ufoo -e "SELECT * FROM information_schema.INNODB_FIELDS;"
#  +--------------------+--------------------+-----+
#  | INDEX_ID           | NAME               | POS |
#  +--------------------+--------------------+-----+
#  ...
#  | 0x313539           | col1234567890      |   0 |
#  +--------------------+--------------------+-----+
```

Hi Mr. Fu,

What we need is the output from SHOW GRANTS FOR ......

If there is none , please change category to Docker.

The following is the result of the `SHOW GRANTS` command with the user `foo` login:

mysql> SHOW GRANTS;
+---------------------------------+
| Grants for foo@%                |
+---------------------------------+
| GRANT USAGE ON *.* TO `foo`@`%` |
+---------------------------------+
1 row in set (0.00 sec)

The full script to reproduce it:

#!/bin/bash
docker container rm some-mysql -f
docker run -e MYSQL_ALLOW_EMPTY_PASSWORD=1 -p 3306:3306 -itd --name some-mysql mysql:9.1.0
echo "Waiting the server start...";
sleep 15    # wait for the MySQL server to start

docker exec -it some-mysql mysql -uroot -e "USE mysql; CREATE TABLE tbl1 (col1234567890 INT); CREATE INDEX idx1 ON tbl1 (col1234567890);"
docker exec -it some-mysql mysql -uroot -e "CREATE USER foo;"

docker exec -it some-mysql mysql -ufoo -e "SHOW GRANTS;"
#  +---------------------------------+
#  | Grants for foo@%                |
#  +---------------------------------+
#  | GRANT USAGE ON *.* TO `foo`@`%` |
#  +---------------------------------+

docker exec -it some-mysql mysql -uroot -e "SHOW GRANTS FOR foo;"
#  +---------------------------------+
#  | Grants for foo@%                |
#  +---------------------------------+
#  | GRANT USAGE ON *.* TO `foo`@`%` |
#  +---------------------------------+

# Unexpected result: the non-privileged user can see the column name
docker exec -it some-mysql mysql -ufoo -e "SELECT * FROM information_schema.INNODB_FIELDS;"
#  +--------------------+--------------------+-----+
#  | INDEX_ID           | NAME               | POS |
#  +--------------------+--------------------+-----+
#  ...
#  | 0x313539           | col1234567890      |   0 |
#  +--------------------+--------------------+-----+

I can reproduce it on a MySQL instance initialized with this command:

mysqld --initialize-insecure -uroot

I haven't tried other MySQL instances yet. I will try.

Hi Mr. Fu,

It seems that you are correct in your bug report.

Can you just provide us with a link to the page in our Reference Manual which claims that:

"You must have the PROCESS privilege to query this table. "

As soon as you provide us with that info, we shall verify this bug report.

Sure. This website provides such information:

https://dev.mysql.com/doc/refman/9.1/en/information-schema-innodb-fields-table.html

You can search for the word "PROCESS" on the page to find it.

Thank you Mr. Fu,

For your feedback.

This is now a verified bug report for the version 8.0 and all higher versions.

Since that page can be applied to all tables in that schema, bug #116954 is denoted as a "Duplicate".