hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jitendra Nath Pandey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-10757) KMSClientProvider combined with KeyProviderCache can result in wrong UGI being used
Date Fri, 12 Aug 2016 06:16:20 GMT

    [ https://issues.apache.org/jira/browse/HDFS-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418409#comment-15418409

Jitendra Nath Pandey commented on HDFS-10757:

  I think storing the {{actualUgi}} in KMSClientProvider is incorrect because the providers
are cached for a long time, and the currentUGI may be completely different from the actualUGI.
 Therefore, it may be a good idea to consider removing actualUgi from KMSClientProvider. I
am inclined to say that setting up of the UGI should be done by client code using the FileSystem.
The KMSClientProvider on every call should only check following: If the currentUGI has a realUgi,
us the realUgi as actualUgi or use the currentUgi as the actualUgi. 
  I may not have the whole context on why actualUgi was added in the constructor of KMSClientProvider,
but would like to understand.

> 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

To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org

View raw message