[ https://issues.apache.org/jira/browse/HDFS-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419682#comment-15419682 ]
Jitendra Nath Pandey commented on HDFS-10757: --------------------------------------------- [~asuresh], thanks for explaining the context. In this context it works because the server has a login user that is stored as the actualUgi and that is the one always needed, but in some other scenarios as in HADOOP-13381 the actualUgi becomes incorrect. Many servers, that are processing an incoming request that was authenticated via proxy mechanism, setup a proxy-UGI with a real user without credentials, because the credentials of the real-user are not really available on the server. Therefore, the proxy-ugi is relevant for real authentication only in the context of a client. The proxyUgi setup by the server in this context should not be propagated for further calls to other services. That means a new proxy user should be explicitly setup to make further calls. Suppose a general flow goes like this: (===> denotes a remote call) client1 ====> Server1 (Hive, Oozie) Authenticates and creates ugi1----> Server1 Processes ---> Server1 creates client2 to read encrypted data ===> Server2 (NN or KMS) When Server1 authenticates client1 it creates a ugi1 (which may be a proxy ugi) to preserve the context in which authentication of client1 was performed. Now when Sever1 instantiates a client2 to make a call to Server2 it should not use ugi1 because the authentication context in ugi1 is not relevant for this call. In my opinion a new ugi2 should be explicitly setup, which has the right credentials. > 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 > Priority: Critical > > 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: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org