LuciferYang opened a new pull request, #13874: URL: https://github.com/apache/gravitino/pull/13874
### What changes were proposed in this pull request? `LoadTableAuthzHandler` now treats a multi-level request with a metadata-table name as a metadata-table request only when the backend does not resolve it to a real table: the namespace does not exist, or loading the name returns a metadata table. `tableExists` cannot be used here, because the backends also resolve `[db, t].files` to the files table of `db.t`. Otherwise the request goes through normal table authorization. This matches the Iceberg client, which loads the full name and falls back to the metadata table on 404. If the namespace check fails, the handler returns 404 as before. If loading the name fails for any reason other than a missing table, the request goes on so the real load reports the error; a 404 there would make the client read the metadata table of a different table. The load goes through a new `IcebergCatalogWrapper.resolvesToMetadataTable`, so it runs in the wrapper's Kerberos context. ### Why are the changes needed? The handler rejected every multi-level request with a metadata-table name, so a real table called `files`, `snapshots` and so on in a hierarchical schema always got 404, even for its owner. Fix: #13870 ### Does this PR introduce _any_ user-facing change? Tables with metadata-table names in nested namespaces can be loaded. A request with such a name in a multi-level namespace now costs a namespace check on the backend, plus a table load when the namespace exists. ### How was this patch tested? New `TestLoadTableAuthzHandler`, on an `InMemoryCatalog`: - a real table `files` in the hierarchical schema `a.b` reaches authorization, also when a table `a.b` exists; - `db.t.files` still gets 404 when namespace `[db, t]` does not exist, and when it exists next to table `db.t` but has no table `files`; - a failing namespace check still gets 404, and a failing load in an existing namespace goes on to authorization. -- 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]
