[
https://issues.apache.org/jira/browse/HDFS-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15599481#comment-15599481
]
Brahma Reddy Battula commented on HDFS-10757:
---------------------------------------------
After this commit {{TestKMS}} testcases are failing,[QA Link|
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/202/testReport/]
HADOOP-13748 to track this failues.
{noformat}
java.lang.AssertionError: Key k1 already exists in
jceks://file@/testptch/hadoop/hadoop-common-project/hadoop-kms/target/78df8767-fddd-4ac6-8f9c-55f7702a4427/kms.keystore
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.hadoop.crypto.key.kms.server.TestKMS$10$4.run(TestKMS.java:1326)
at
org.apache.hadoop.crypto.key.kms.server.TestKMS$10$4.run(TestKMS.java:1317)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1795)
at
org.apache.hadoop.crypto.key.kms.server.TestKMS.doAs(TestKMS.java:291)
at
org.apache.hadoop.crypto.key.kms.server.TestKMS.access$100(TestKMS.java:79)
{noformat}
*How jenkins missed here..? As it's raised in HDFS ,all the hadoop-common
testcases did not run.*
IMO, we should revert this and *{color:red}move to common{color}* and then
fix the testcase.
> KMSClientProvider combined with KeyProviderCache can result in wrong UGI
> being used
> -----------------------------------------------------------------------------------
>
> Key: HDFS-10757
> URL: https://issues.apache.org/jira/browse/HDFS-10757
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Xiaoyu Yao
> Priority: Critical
> Fix For: 2.8.0, 3.0.0-alpha2
>
> Attachments: HDFS-10757.00.patch, HDFS-10757.01.patch,
> HDFS-10757.02.patch, HDFS-10757.03.patch
>
>
> ClientContext::get gets the context from CACHE via a config setting based
> name, then KeyProviderCache stored in ClientContext gets the key provider
> cached by URI from the configuration, too. These would return the same
> KeyProvider regardless of current UGI.
> KMSClientProvider caches the UGI (actualUgi) in ctor; that means in
> particular that all the users of DFS with KMSClientProvider in a process will
> get the KMS token (along with other credentials) of the first user, via the
> above cache.
> Either KMSClientProvider shouldn't store the UGI, or one of the caches should
> be UGI-aware, like the FS object cache.
> Side note: the comment in createConnection that purports to handle the
> different UGI doesn't seem to cover what it says it covers. In our case, we
> have two unrelated UGIs with no auth (createRemoteUser) with bunch of tokens,
> including a KMS token, added.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
