Doris-Breakwater commented on issue #69893: URL: https://github.com/apache/doris/issues/69893#issuecomment-6519561532
The report is strongly supported by the FE code as an audit statement-classification defect: executing the `WHERE` form replaces the executor's original `SHOW` statement with an internal `SELECT` plan, and audit classification subsequently reads that replacement. The internal query itself is an intentional implementation of filtering; the problem is losing the original statement identity for auditing. **Verified source evidence** I traced the public `4.0.8` tag (commit `bc8ea1bac6d62d92cdebd2e3ac33cc668961ec36`). This is a reference version, not an assumption about the reporter's installed build. 1. `LogicalPlanBuilder.visitShowTables()` initially constructs a `ShowTableCommand` for both filtered and unfiltered forms. Its base class, [`ShowCommand.stmtType()`](https://github.com/apache/doris/blob/bc8ea1bac6d62d92cdebd2e3ac33cc668961ec36/fe/fe-core/src/main/java/org/apache/doris/nereids/trees/plans/commands/ShowCommand.java#L42-L60), returns `SHOW`. 2. With a `WHERE` clause, [`ShowTableCommand.executeWhere()`](https://github.com/apache/doris/blob/bc8ea1bac6d62d92cdebd2e3ac33cc668961ec36/fe/fe-core/src/main/java/org/apache/doris/nereids/trees/plans/commands/ShowTableCommand.java#L116-L144) builds a query against `information_schema.tables`, including the table-type alias and database filter. Plain `SHOW FULL TABLES` and the `LIKE` form take a different path. 3. [`Utils.buildLogicalPlan()` / `executePlan()`](https://github.com/apache/doris/blob/bc8ea1bac6d62d92cdebd2e3ac33cc668961ec36/fe/fe-core/src/main/java/org/apache/doris/nereids/util/Utils.java#L639-L662) generate a `SELECT`, wrap its plan in a `LogicalPlanAdapter`, and call `executor.setParsedStmt(adapter)` on the **same executor**. They do not restore the original statement afterward. The SELECT result sink reports `StmtType.SELECT`. 4. After execution, [`ConnectProcessor`](https://github.com/apache/doris/blob/bc8ea1bac6d62d92cdebd2e3ac33cc668961ec36/fe/fe-core/src/main/java/org/apache/doris/qe/ConnectProcessor.java#L347-L357) passes `executor.getParsedStmt()` to auditing. [`AuditLogHelper.getStmtType()`](https://github.com/apache/doris/blob/bc8ea1bac6d62d92cdebd2e3ac33cc668961ec36/fe/fe-core/src/main/java/org/apache/doris/qe/AuditLogHelper.java#L460-L471) uses the adapter's logical-plan type, explaining `SELECT` even when the logged SQL text is the original `SHOW`. The same command/helper/classifier pattern is also present in the inspected `4.1.4` source (`ad35a140c7fd0b842f18c23300bac581f7d04326`). This is source inspection, not a live reproduction or confirmation that every 4.x build is affected. **Information still needed** - Exact FE version and build commit, preferably the version/build information from the FE startup log; “4.x” is too broad for selecting a fix or backport. - Redacted raw audit records for the supplied statement, plus `SHOW FULL TABLES`, `SHOW FULL TABLES LIKE 't%'`, and an ordinary `SELECT 1` from the same session. Include SQL text, statement type, query ID, timestamp, status, and internal-query flag if available. Specify whether these are from `fe.audit.log`, the audit table, or another audit consumer, and whether multiple records appear for one execution. - Whether the statement succeeds and returns the expected tables. No profile is needed for this classification issue; FE error logs are useful if execution also fails. **Recommended next steps for maintainers** - Reproduce on the exact build and add coverage that asserts the **final audit event**, not just the parser's initial statement type. Cover filtered/unfiltered/`LIKE` SHOW, ordinary SELECT, and failure paths. - Preserve the original user statement's classification across internal execution. Review both the executor and statement-context mutation when choosing between scoped restoration and separately retained audit metadata. - Account for [`executeInternalQuery()`](https://github.com/apache/doris/blob/bc8ea1bac6d62d92cdebd2e3ac33cc668961ec36/fe/fe-core/src/main/java/org/apache/doris/qe/StmtExecutor.java#L2017-L2111): it also changes query state and emits an audit event in `finally`. Restoring `parsedStmt` only after it returns does not address that earlier event. Verify event count, statement identity, and internal-query attribution together. - Review the other `Utils.executePlan()` callers (`ShowColumnsCommand`, `ShowDatabasesCommand`, and `ShowTableStatusCommand`) for the same pattern; their affected runtime scope remains to be tested. No Doris code was modified, and no runtime test was executed during this investigation. Breakwater-GitHub-Analysis-Slot: slot_455fc757a09f -- 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]
