[
https://issues.apache.org/jira/browse/HDFS-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419234#comment-15419234
]
Arun Suresh edited comment on HDFS-10757 at 8/12/16 6:09 PM:
-------------------------------------------------------------
Hmmm... I think I remember the context for why it was implemented as such.
bq. If the currentUgi is a proxy user it will have a real UGI.
currentUgi.getRealUser() should give us the actual ugi.
That is true, but the KMSCP was being implemented around the same time as
HADOOP-10835. That JIRA was meant to plumb proxy user through HTTP. If you look
at this
[snippet|https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/token/delegation/web/DelegationTokenAuthenticationFilter.java#L247-L267]
of code, you will notice that if the currentUser is authenticated via a
delegation token, the realUser is actually a dummy user created via
{{UserGroupInformation.createRemoteUser()}} and does not have any credentials
to create the connection, which is why I guess it was decided to have a
loginUgi/actualUgi created in the KMSCP constructor.
was (Author: asuresh):
Hmmm... I think I remember the context for why it was implemented as such.
bq. If the currentUgi is a proxy user it will have a real UGI.
currentUgi.getRealUser() should give us the actual ugi.
That is true, but the KMSCP was being implemented around the same time as
HADOOP-10835. That JIRA was meant to plumb proxy user through HTTP. If you look
at this
[snippet|https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/token/delegation/web/DelegationTokenAuthenticationFilter.java#L247-L267]
of code, you will notice that if the currentUser is authenticated via a
delegation token, the realUser is actually a dummy user created via {{
UserGroupInformation.createRemoteUser()}} and does not have any credentials to
create the connection, which is why I guess it was decided to have a
loginUgi/actualUgi created in the KMSCP constructor.
> 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: [email protected]
For additional commands, e-mail: [email protected]
