Copilot commented on code in PR #14407:
URL: https://github.com/apache/gravitino/pull/14407#discussion_r4436475520
##########
catalogs/catalog-fileset/src/main/java/org/apache/gravitino/catalog/fileset/FilesetCatalogOperations.java:
##########
@@ -218,22 +226,47 @@ public class FilesetCatalogOperations extends
ManagedSchemaOperations
}
static class FileSystemCacheKey {
+ // The settings that decide how an HDFS file system logs in. The authority
carries the principal
+ // only without its realm, and a location without a scheme has no
authority at all.
+ private static final List<String> AUTHENTICATION_KEYS =
+ ImmutableList.of(
+ AuthenticationConfig.AUTH_TYPE_KEY,
+ AuthenticationConfig.IMPERSONATION_ENABLE_KEY,
+ KerberosConfig.PRINCIPAL_KEY,
+ KerberosConfig.KEY_TAB_URI_KEY,
+ HADOOP_SECURITY_AUTHENTICATION,
+ GRAVITINO_BYPASS + HADOOP_SECURITY_AUTHENTICATION,
+ HADOOP_SECURITY_PRINCIPAL,
+ GRAVITINO_BYPASS + HADOOP_SECURITY_PRINCIPAL,
+ HADOOP_SECURITY_KEYTAB,
+ GRAVITINO_BYPASS + HADOOP_SECURITY_KEYTAB,
+ CONFIG_RESOURCES);
Review Comment:
The allowlist omits `hadoop.security.authentication.kerberos.krb5.conf`,
which `HDFSFileSystemProxy.initKerberosUgi()` passes to `KerberosClient` to
configure Kerberos before login. Two filesets with identical
type/principal/keytab but different krb5.conf paths still get equal cache keys,
so the second reuses the first login without applying its Kerberos
configuration. Include `HADOOP_KRB5_CONF` and its `gravitino.bypass.` form, and
add both to the regression test.
--
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]
