Bug #118907 The privileges of a user persisted by NDB_STORE_USER may be corrupted after upgrading from 8.0 to 8.4.
Submitted: 28 Aug 8:09
Reporter: ZHAO SONG Email Updates:
Status: Open Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S2 (Serious)
Version:8.4.X OS:Any
Assigned to: CPU Architecture:Any

[28 Aug 8:09] ZHAO SONG 
Description:
MySQL deprecated the SET_USER_ID privilege starting in 8.4, and this change conflicts with NDB’s current implementation of NDB_STORE_USER.

NDB implements NDB_STORE_USER by storing the corresponding plain SQL statements (such as CREATE USER, GRANT, etc.) in an internal table. On startup, MySQL replays these SQL statements to restore the users.

The issue occurs if a user is granted ALL (or explicitly SET_USER_ID) along with NDB_STORE_USER. In this case, the persisted SQL in the internal table includes SET_USER_ID. After upgrading to MySQL 8.4, the new version no longer recognizes this privilege and returns a Syntax error when applying the SQL. As a result, the persisted privileges cannot be restored.

During the upgrade process, the new mysqld binary does perform conversion of the DD and system tables, but these changes are local only. The persisted information in NDB remains incorrect. This means that any newly added mysqld instance, or any reinitialized mysqld, will fail to restore the grant information from NDB—defeating the purpose of using NDB_STORE_USER.

How to repeat:
1. Create a user and grant 'ALL' (which includes NDB_STORE_USER and SET_USER_ID) to it on MySQL 8.0.

2. Upgrade the cluster to MySQL 8.4.

3. Initialize mysqld and connect it to NDB.

4. Observe that the restored user from NDB_STORE_USER has incorrect privileges.

Suggested fix:
The quick solution is to handle compatibility when parsing the plain SQL. However, this isn’t 100% safe—you must ensure that the persisted privileges exactly match those supported by the corresponding MySQL version.