You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
New setting metastore.iceberg.catalog.client-supplied-owner.enabled (default false).
When disabled, the REST catalog records the authenticated caller as owner of new
tables and views. Embedded HiveCatalog keeps its current behaviour
(iceberg.hive.client-supplied-owner.enabled, default true).
hive.metastore.table.owner, Authorized and hive.metastore.view.authorized are
treated as HMS-managed view properties: they are not copied into HMS parameters, and
the REST catalog drops them from view create/update requests.
REST view responses report the owner and Authorized state recorded in HMS for the
returned metadata version.
HiveRESTCatalogClient maps hive.metastore.view.authorized back to the Authorized
view parameter; MetastoreUtil keeps the HMS-recorded owner when converting a view.
Why are the changes needed?
Keeps owner and view authorization state consistent with what HMS records. See HIVE-29992.
Does this PR introduce any user-facing change?
Yes. With the default configuration, the Iceberg REST catalog sets the owner of new
tables and views to the authenticated caller instead of a client-provided value. The
previous behaviour can be restored with metastore.iceberg.catalog.client-supplied-owner.enabled=true.
How was this patch tested?
New and updated unit tests: TestRESTViewDeferredAuthorization, TestIcebergAuthorizer, TestIcebergViewSupport, TestHiveHadoopUtil; new itest TestHiveRESTCatalogClientViewAuthorization.
- Add metastore.iceberg.catalog.client-supplied-owner.enabled (default
false). When disabled, the REST catalog records the authenticated
caller as owner of new tables and views. Embedded HiveCatalog keeps
its current behaviour (iceberg.hive.client-supplied-owner.enabled,
default true).
- Treat hive.metastore.table.owner, Authorized and
hive.metastore.view.authorized as HMS-managed view properties: they
are not copied into HMS parameters, and the REST catalog drops them
from view create and update requests.
- REST view responses report the owner and Authorized state recorded
in HMS for the returned metadata version, as hive.metastore.table.owner
and hive.metastore.view.authorized.
- HiveRESTCatalogClient maps hive.metastore.view.authorized back to the
Authorized view parameter; MetastoreUtil keeps the HMS-recorded owner
when converting a view.
- Add tests.
Co-Authored-By: Claude <noreply@anthropic.com>
This PR makes HMS the source of truth for Iceberg REST catalog ownership and view authorization state, while preserving embedded HiveCatalog owner defaults.
Changes:
Adds a default-off setting for client-supplied owners and aligns owner resolution with authorization checks.
Filters HMS-managed view properties from requests and reports recorded owner and authorization state in REST responses.
Updates Hive client conversion and adds unit and integration coverage.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
The projected getTables lookup does not catch UnknownDBException, so a namespace dropped during view loading causes HTTP 500 instead of the intended missing-object fallback.
No open issues 🎉
1 previously missed issue
In code that hasn't changed since last review
Handle UnknownDBException when fetching missing catalog state
The projected getTables API throws UnknownDBException for a missing database/catalog (GetTableHandler.java:278–281), not NoSuchObjectException. Consequently, if the namespace is dropped between loading the view metadata and fetching its HMS state, this lookup throws a RuntimeException and the REST request returns HTTP 500 instead of using the intended missing-object fallback. Catch UnknownDBException here as well and return null.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Owner and deferred-authorization semantics span REST, HMS, and HiveServer2, but mock-based integration coverage leaves default and opt-in behavior needing validation with the deployment’s real authorization plugin.
The reason will be displayed to describe this comment to others. Learn more.
These reserved properties related methods as well as the withViewAuthorization method increase the size of the adapter class notably. I'm thinking if they can be moved somewhere. I thought about HMSAuthorizer companion for IcebergAuthorizer might be one way to deal with it. What are your thoughts?
The reason will be displayed to describe this comment to others. Learn more.
Moved to a new HMSViewProperties class in cb61815: it holds the reserved-property filtering and the view state reported in responses; the adapter only delegates. I kept it separate from IcebergAuthorizer since it doesn't make authorization decisions, it filters and reports HMS-managed properties.
The reason will be displayed to describe this comment to others. Learn more.
[nitpick] I don't know if that's better but it could be separated into a single method with boolean flag and could be used also in HiveRESTCatalogClient
like this:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
metastore.iceberg.catalog.client-supplied-owner.enabled(defaultfalse).When disabled, the REST catalog records the authenticated caller as owner of new
tables and views. Embedded
HiveCatalogkeeps its current behaviour(
iceberg.hive.client-supplied-owner.enabled, defaulttrue).hive.metastore.table.owner,Authorizedandhive.metastore.view.authorizedaretreated as HMS-managed view properties: they are not copied into HMS parameters, and
the REST catalog drops them from view create/update requests.
Authorizedstate recorded in HMS for thereturned metadata version.
HiveRESTCatalogClientmapshive.metastore.view.authorizedback to theAuthorizedview parameter;
MetastoreUtilkeeps the HMS-recorded owner when converting a view.Why are the changes needed?
Keeps owner and view authorization state consistent with what HMS records. See HIVE-29992.
Does this PR introduce any user-facing change?
Yes. With the default configuration, the Iceberg REST catalog sets the owner of new
tables and views to the authenticated caller instead of a client-provided value. The
previous behaviour can be restored with
metastore.iceberg.catalog.client-supplied-owner.enabled=true.How was this patch tested?
New and updated unit tests:
TestRESTViewDeferredAuthorization,TestIcebergAuthorizer,TestIcebergViewSupport,TestHiveHadoopUtil; new itestTestHiveRESTCatalogClientViewAuthorization.🤖 Generated with Claude Code