MonkeyCanCode commented on code in PR #3494:
URL: https://github.com/apache/polaris/pull/3494#discussion_r2714057152
##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergCatalog.java:
##########
@@ -1409,6 +1409,22 @@ public void doRefresh() {
Set.of(PolarisStorageActions.READ,
PolarisStorageActions.LIST));
return TableMetadataParser.read(fileIO, metadataLocation);
});
+
+ // After a refresh, re-load the FileIO with the new table metadata
properties to
+ // ensure the right permissions are present for subsequent file system
interactions.
+ if (currentMetadata != null) {
+ tableFileIO =
+ loadFileIOForTableLike(
+ tableIdentifier,
+ StorageUtil.getLocationsUsedByTable(currentMetadata),
+ resolvedEntities,
+ new HashMap<>(currentMetadata.properties()),
+ Set.of(
+ PolarisStorageActions.READ,
+ PolarisStorageActions.WRITE,
+ PolarisStorageActions.LIST));
Review Comment:
Yeah, resetting the permissions here does feel a bit odd. So we may need to
do some refactor to fix this bug. Based on my understanding, the issue reporter
faced was AWS assumeRole credentials became stale after table creation due to
cached FileIO thus a quick "workaround" here is to reset it to full which then
allowed the reporter to continue the test and validated the root cause. If we
do want to keep the FileIO cached, we may need to do reader/writer FileIO
separately to follow the least privileges pattern. Another alternative would be
creating new FileIO per operation and right permissions for them. Any preferred
route or better solutions?
--
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]
