agnes-xinyi-lu commented on code in PR #8189:
URL: https://github.com/apache/gravitino/pull/8189#discussion_r2294322094
##########
iceberg/iceberg-common/src/main/java/org/apache/gravitino/iceberg/common/ClosableHiveCatalog.java:
##########
@@ -60,4 +72,64 @@ public void close() throws IOException {
}
});
}
+
+ @FunctionalInterface
+ interface Executable<R> {
+ R run() throws Exception;
+ }
+
+ public <R> R execute(Executable<R> runnable) {
+ try {
+ return runnable.run();
+ } catch (Exception e) {
+ LOGGER.error("Failed to execute runnable: {}", runnable, e);
+ throw new RuntimeException(e);
+ }
+ }
+
+ public Catalog.TableBuilder buildTable(TableIdentifier identifier, Schema
schema) {
Review Comment:
It will not be scalable if we only fix createTable. updateTable also has the
same problem. Same with create/updateView.
The solution could be adding another layer of impersonation on Iceberg
TableOperations where it does the real load/update table. Or move the
impersonation up a level to catalog wrapper.
This is a bit off topic of this problem but still related if we impersonate
the catalog wrapper, is it OK to make impersonation more generic instead of
just on kerberorized HiveCatalog? Most companies have their own network and
authentication mechanism, they could use whatever authenticator that security
allows. And the service that are talking to Gravitino IRC server, could
impersonate any user in any way they want, as long as Gravitino thinks it's a
superuser that could impersonate others. Kerberos impersonation could be one of
the implementations.
--
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]
