HIVE-29248: Propagate HiveAccessControlException to HiveCatalog#6171
HIVE-29248: Propagate HiveAccessControlException to HiveCatalog#6171okumin merged 3 commits intoapache:masterfrom
Conversation
cce3ff3 to
0e8b53a
Compare
0e8b53a to
3598bd1
Compare
3598bd1 to
cf0be80
Compare
iceberg/iceberg-catalog/src/main/java/org/apache/iceberg/hive/HiveClientPool.java
Show resolved
Hide resolved
|
|
I verified that a client would see a ForbiddenException for sure |
|
Merged. @deniskuzZ Thanks for reviewing this PR! |
|
@okumin Hi, I have a question regarding this PR. I ran into an issue with using StorageBasedAuthorizationProvider where AccessControlExceptions were not propagated to the client immediately, causing the request to wait until the metastore timeout. |
|
@Chaho12 |
…he#6171) * Add test cases to reproduce HiveAccessControlException * Classify HiveAccessControlException as ForbiddenException * Add core classifier
…he#6171) * Add test cases to reproduce HiveAccessControlException * Classify HiveAccessControlException as ForbiddenException * Add core classifier



What changes were proposed in this pull request?
Add a prefixed message,
Got exception: org.apache.hadoop.hive.ql.security.authorization.plugin.HiveAccessControlException, to MetaException when HiveMetaStoreAuthorizer handles HiveAccessControlException, and make HiveCatalog translate it to Iceberg's ForbiddenException.This Pull Request implements the first option in the following document, and I'm not obsessed with this option; I chose it first because the change is minimal(easy to revert). I'm open to Option 2 or 3, or another suggestion.
https://docs.google.com/document/d/1SMvIud9k5lVSzqjgCzohHH59oW5MWAwA9BW-pPr9yIc/edit?usp=sharing
https://issues.apache.org/jira/browse/HIVE-29248
Why are the changes needed?
Currently, when Ranger rejects an access, HiveMetastore throws
MetaException(message:<Message thrown by Ranger>), and a Thrift client can't get more information than the error message implemented in Apache Ranger. It's inconvenient for an Iceberg client such as Spark to distinguish the root cause and Iceberg REST API can't return a proper status code, i.e., 403.Does this PR introduce any user-facing change?
No. The error message will contain more information.
How was this patch tested?
I added integration tests to verify that thrown exceptions are handled correctly.