[ https://issues.apache.org/jira/browse/HADOOP-15997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Wei-Chiu Chuang updated HADOOP-15997: ------------------------------------- Description: After HADOOP-14445, KMS client always authenticates itself using the credentials from login user, rather than current user. {noformat} 2018-12-07 15:58:30,663 DEBUG [main] org.apache.hadoop.crypto.key.kms.KMSClientProvider: Using loginUser when Kerberos is enabled but the actual user does not have either KMS Delegation Token or Kerberos Credentials {noformat} The log message {{"Using loginUser when Kerberos is enabled but the actual user does not have either KMS Delegation Token or Kerberos Credentials"}} is printed because {{KMSClientProvider#containsKmsDt()}} is null when it definitely has the kms delegation token. In fact, {{KMSClientProvider#containsKmsDt()}} should select delegation token using {{clientTokenProvider.selectDelegationToken(creds)}} rather than checking if its dtService is in the user credentials. This is done correctly in {{KMSClientProvider#createAuthenticatedURL}} though. We found this bug when it broke Cloudera's Backup and Disaster Recovery tool. [~daryn] [~xiaochen] mind taking a look? HADOOP-14445 is a huge patch but it is almost perfect except for this bug. was: After HADOOP-14445, KMS client always authenticates itself using the credentials from login user, rather than current user. {noformat} 2018-12-07 15:58:30,663 DEBUG [main] org.apache.hadoop.crypto.key.kms.KMSClientProvider: Using loginUser when Kerberos is enabled but the actual user does not have either KMS Delegation Token or Kerberos Credentials {noformat} The log message is printed because {{KMSClientProvider#containsKmsDt()}} is null when it definitely has the kms delegation token. In fact, {{KMSClientProvider#containsKmsDt()}} should select delegation token using {{clientTokenProvider.selectDelegationToken(creds)}} rather than checking if its dtService is in the user credentials. This is done correctly in {{KMSClientProvider#createAuthenticatedURL}} though. We found this bug when it broke Cloudera's Backup and Disaster Recovery tool. [~daryn] [~xiaochen] mind taking a look? HADOOP-14445 is a huge patch but it is almost perfect except for this bug. > KMS client uses wrong UGI after HADOOP-14445 > -------------------------------------------- > > Key: HADOOP-15997 > URL: https://issues.apache.org/jira/browse/HADOOP-15997 > Project: Hadoop Common > Issue Type: Bug > Components: kms > Affects Versions: 3.2.0, 3.0.4, 3.1.2 > Environment: Hadoop 3.0.x (CDH6.x), Kerberized, HDFS at-rest > encryption, multiple KMS > Reporter: Wei-Chiu Chuang > Assignee: Wei-Chiu Chuang > Priority: Major > Attachments: HADOOP-15997.001.patch > > > After HADOOP-14445, KMS client always authenticates itself using the > credentials from login user, rather than current user. > {noformat} > 2018-12-07 15:58:30,663 DEBUG [main] > org.apache.hadoop.crypto.key.kms.KMSClientProvider: Using loginUser when > Kerberos is enabled but the actual user does not have either KMS Delegation > Token or Kerberos Credentials > {noformat} > The log message {{"Using loginUser when Kerberos is enabled but the actual > user does not have either KMS Delegation Token or Kerberos Credentials"}} is > printed because {{KMSClientProvider#containsKmsDt()}} is null when it > definitely has the kms delegation token. > In fact, {{KMSClientProvider#containsKmsDt()}} should select delegation token > using {{clientTokenProvider.selectDelegationToken(creds)}} rather than > checking if its dtService is in the user credentials. > This is done correctly in {{KMSClientProvider#createAuthenticatedURL}} though. > We found this bug when it broke Cloudera's Backup and Disaster Recovery tool. > > [~daryn] [~xiaochen] mind taking a look? HADOOP-14445 is a huge patch but it > is almost perfect except for this bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org