GRANT can create a 33-byte user that CREATE USER rejects

Self Checks

• I have read the Contributing Guide.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

OceanBase version

OceanBase CE 5.0.2.0, revision 1-d128661ca4f5b3d167c1928e556d70d2f901baef, built from source with Release+AddressSanitizer.

Self Hosted

Self Hosted (Source)

Environment

OS: Ubuntu 22.04.5 LTS, Linux 6.5.13-5-pve x86_64 Compiler: Clang 17.0.6 Topology: one-zone observer, loopback listeners Tenant: MySQL mode Client: obclient from the same source dependency bundle

Steps to reproduce

Use a disposable MySQL-mode tenant and connect as a tenant administrator. No attachment or custom client is needed.

1. Create a 32-byte account name as a control:

   sql复制

   CREATE USER 'uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu'@'%'
     IDENTIFIED BY 'EdbfPass123!';

   This succeeds.

2. Try the same operation with 33 u characters:

   sql复制

   CREATE USER 'uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu'@'%'
     IDENTIFIED BY 'EdbfPass123!';

   The server rejects it:

   复制

   ERROR 1470 (HY000): String 'uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu' is too long for user name (should be no longer than 32)

3. Use GRANT ... IDENTIFIED BY, which implicitly creates a missing user, with exactly the same 33-byte name:

   sql复制

   GRANT SELECT ON *.*
     TO 'uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu'@'%'
     IDENTIFIED BY 'EdbfPass123!';

   This succeeds.

4. Confirm that the rejected-by-CREATE USER name now exists:

   sql复制

   SELECT User, Host
     FROM mysql.user
    WHERE User = 'uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu';

   Observed result:

   复制

   uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu  %

5. Remove the synthetic account after the test:

   sql复制

   DROP USER 'uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu'@'%';
   DROP USER 'uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu'@'%';

The authoritative local matrix executed 11/11 cases. It recorded 10 clean cases and this one wrong-result anomaly, then successfully queried SELECT VERSION(), CURRENT_USER().

✔️ Expected Behavior

All SQL paths that create an account should enforce the same maximum user-name length. If MySQL-mode CREATE USER limits names to 32 bytes, implicit creation through GRANT ... IDENTIFIED BY should reject a 33-byte name with the same error and should not add a row to mysql.user.

❌ Actual Behavior

CREATE USER rejects the 33-byte name with error 1470, but GRANT ... IDENTIFIED BY accepts it and creates the account. A subsequent query finds one matching row in mysql.user. The observer remains healthy; this is not a crash.

The current GRANT resolver still checks the older OB_MAX_USER_NAME_LENGTH boundary before calling add_user(), while the MySQL-mode CREATE USER path enforces 32 bytes.