geyanggang opened a new issue, #11130:
URL: https://github.com/apache/gravitino/issues/11130
### What would you like to be improved?
When Flink Calcite resolves two-part SQL identifiers (e.g., `schema.table`),
it speculatively calls `loadTable` with different namespace combinations to
find the correct resolution path. If the probed table does not exist, the
authorization interceptor returns 403 (`ForbiddenException`) before the method
can return 404 (`NoSuchTableException`). This blocks Calcite's fallback
resolution and causes SQL validation failures.
Example: user sets `useDatabase("flink_db")` then executes `SELECT * FROM
flink_db_test.my_table`. Calcite first probes `loadTable("flink_db",
"flink_db_test")` — a non-existent table. Authorization rejects it with 403,
preventing Calcite from falling back to the correct interpretation
(`schema=flink_db_test`, `table=my_table`).
Workaround: use three-part references (`catalog.schema.table`) or
`useDatabase("target_schema")` before queries.
### How should we improve?
When authorization fails for a `loadTable` operation, check whether the
target table actually exists before returning 403. If the table does not exist,
let the request proceed so the method returns 404 naturally. Authorization
should only apply to existing resources — returning 403 for a non-existent
resource is misleading and breaks Flink Calcite's standard identifier
resolution.
--
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]
