Doris-Breakwater commented on issue #70340: URL: https://github.com/apache/doris/issues/70340#issuecomment-6680118579
Source inspection confirms the reported row-count regression at `d9d60bee9fea41273206052e7eba9b331c7f9959`. Suggested triage: FE/auth metadata display regression. The issue currently has no labels. **Verified mechanism** - `PasswordPolicy.getInfo()` concatenates two expiration rows, two history rows, and now five failed-login/account-lock rows. `account_locked` is appended unconditionally, including when its value is `false`, so every existing policy produces nine rows. This was introduced by [#67792](https://github.com/apache/doris/pull/67792). See [PasswordPolicy.java](https://github.com/apache/doris/blob/d9d60bee9fea41273206052e7eba9b331c7f9959/fe/fe-core/src/main/java/org/apache/doris/mysql/privilege/PasswordPolicy.java#L487). - `Auth.getAllUserInfo()` initializes a 32-element row with empty strings, then copies policy values to positions 24–31 only when the policy list has exactly eight rows. With nine rows, the entire copy is skipped. See [Auth.java](https://github.com/apache/doris/blob/d9d60bee9fea41273206052e7eba9b331c7f9959/fe/fe-core/src/main/java/org/apache/doris/mysql/privilege/Auth.java#L2400). - The SQL path reaches this builder through `FrontendServiceImpl.showUser()`. The [BE schema scanner](https://github.com/apache/doris/blob/d9d60bee9fea41273206052e7eba9b331c7f9959/be/src/information_schema/schema_user_scanner.cpp#L107) copies the returned strings by column position; it does not recover the skipped policy values. **Scope qualifications** The central diagnosis is correct, but “every column is empty” needs one qualification: `password_policy.history_passwords` is deliberately overwritten with `***` after the copy block. Preserve that masking in any fix. Also, an unset `lock_time` legitimately displays an empty string. An identity without a policy already returns an empty policy list; that case should not be confused with this regression. This code establishes a metadata projection defect; it does not establish that policy persistence or login enforcement is broken. No Doris cluster reproduction or FE tests were run during this investigation. **Recommended fix and verification** 1. Populate the eight existing schema columns using an explicit policy-name-to-column mapping, independent of policy row count/order, and retain the existing history masking and account-visibility filtering. Changing the condition to accept nine rows while copying the whole list would attempt `set(32, ...)` on a 32-element row. 2. Keep adding an `account_locked` column as a separate schema decision. If desired, update the FE [MysqlDBTable schema](https://github.com/apache/doris/blob/d9d60bee9fea41273206052e7eba9b331c7f9959/fe/fe-core/src/main/java/org/apache/doris/catalog/MysqlDBTable.java#L63), row builder, and BE scanner descriptors together. 3. Add a regression using the supplied `CREATE USER` and a privileged reader: assert `num_failed_login = '3'`, `password_lock_seconds = '86400'`, initial `failed_login_counter = '0'`, and `history_passwords = '***'`. Verify the other non-sensitive policy columns against the policy source, allowing legitimately unset values. Cover both administrative lock states, missing policies, an additional/reordered policy row, and existing visibility restrictions. **Missing information / interim inspection** The supplied revision and reproducer are sufficient to identify this source defect; logs or a query profile are not needed to explain it. For runtime confirmation, attach the relevant column output with the queried `Host`/`User` identity and caller privilege level. If `history_passwords` is actually blank rather than `***`, include the exact running FE build identity because that differs from this revision's code. `SHOW CREATE USER` bypasses this guard for configured policy settings and `ACCOUNT_LOCK`, but does not expose live counters. There is also an authorized `/auth/<user-identity>` proc path: [UserPropertyProcNode](https://github.com/apache/doris/blob/d9d60bee9fea41273206052e7eba9b331c7f9959/fe/fe-core/src/main/java/org/apache/doris/common/proc/UserPropertyProcNode.java#L47) appends policy rows directly, so the administrative lock is not exclusively available through `SHOW CREATE USER`. Breakwater-GitHub-Analysis-Slot: slot_02649f4d968c -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
