wangyum opened a new pull request, #6888: URL: https://github.com/apache/hive/pull/6888
JIRA: [HIVE-30195](https://issues.apache.org/jira/browse/HIVE-30195) (umbrella epic: [HIVE-19715](https://issues.apache.org/jira/browse/HIVE-19715) · related: [HIVE-30196](https://issues.apache.org/jira/browse/HIVE-30196) — same class of gap, the limit-check enforcement in the same RPC, handled in a separate PR) ### Problem `get_partitions_with_specs` (introduced by HIVE-20306) skipped `FilterUtils.checkDbAndTableFilters` — the table-level metastore filter hook check that every regular partition listing RPC performs upfront in `GetPartitionsHandler.beforeExecute()` → `authorizeTableForPartitionMetadata()`. With `metastore.server.filter.enabled=true` and a filter hook that hides the table from the caller (server-side result filtering, e.g. masking), the regular listing RPCs (`get_partitions`, `get_partitions_by_names`, `get_partitions_with_auth`, `get_partitions_by_filter`, `get_partitions_by_expr`, `get_partitions_ps`, `get_partitions_ps_with_auth`) fail fast with `NoSuchObjectException`, while `get_partitions_with_specs` still fetched all matching partitions and only applied partition-level filtering (`FilterUtils.filterPartitionsIfEnabled`) afterwards — whether rows are exposed depends on the hook's `filterPartitions` implementation. Note: deployments that configure `HiveMetaStoreAuthorizer` as a pre-event listener are not affected — authorization is enforced by the pre-event; this gap affects the filter-hook (visibility/masking) mechanism specifically. ### What this change does Adds the missing check in `HMSHandler.get_partitions_with_specs`, right after `firePreEvent(new PreReadTableEvent(table, this))`, mirroring `GetPartitionsHandler.beforeExecute()` (including identifier normalization): ```java FilterUtils.checkDbAndTableFilters(isServerFilterEnabled, filterHook, normalizeIdentifier(catName), normalizeIdentifier(parsedDbName[DB_NAME]), normalizeIdentifier(tableName)); ``` Authorization ordering is preserved: the pre-event listeners still run before the filter hook check, and the partition-level post-fetch filtering is unchanged. ### Behavior change (only when `metastore.server.filter.enabled=true`; default is unchanged) When the filter hook filters out the database or the table, `get_partitions_with_specs` now fails fast with `NoSuchObjectException`, matching every regular partition listing RPC. Previously it fetched all matching partitions and relied on the hook's post-fetch `filterPartitions` to trim the response. ### Tests `TestFilterHooks.testFilterForPartition` (server-side branch): added the `getPartitionsWithSpecs` assertion next to the existing `getPartitionsByNames` one — with the filter hook blocking the table, the RPC must fail with `NoSuchObjectException` like its siblings. Verified red→green: the new assertion fails without the fix (`getPartitionsWithSpecs() should fail with blocking mode at server side`) and passes with it. Full verification on this branch: `TestFilterHooks` 4/4, `TestHmsServerAuthorization` 5/5 (authorization failure still precedes the filter check), `TestGetPartitionsUsingProjectionAndFilterSpecs` 25/25, `TestRemoteHiveMetaStore#testGetPartitionsWithSpec` and `TestEmbeddedHiveMetaStore#testGetPartitionsWithSpec` pass. -- 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]
