[
https://issues.apache.org/jira/browse/HDFS-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15472868#comment-15472868
]
Jitendra Nath Pandey commented on HDFS-10757:
---------------------------------------------
[~xyao], thanks for the patch. However, I am bit concerned about reliance on
AuthenticationMethod in the UGI, particularly {{AuthenticationMethod.TOKEN}}.
In the context of a server authenticating an incoming request, authentication
method is setup accurately in the RPC layer. However, in a client context, I am
not sure it is set correctly in all cases.
How about just doing following in getActualUGI.
{code}
if (authMethod == UserGroupInformation.AuthenticationMethod.PROXY) {
actualUgi = UserGroupInformation.getCurrentUser().getRealUser();
else {
actualUgi =UserGroupInformation.getCurrentUser();
}
{code}
That essentially means the caller of the API has to setup UGI correctly. I am
also assuming AuthenticationMethod.PROXY is set up correctly in all cases.
However we could also check for
{{UserGroupInformation.getCurrentUser().getRealUser() != null}}.
There is one more angle here, users are not directly calling KMS APIs. They
call DFSClient API which internally calls KMS. The token users must
additionally get KMS tokens and populate the UGI. Yarn job client already takes
care of populating the UGI with KMS delegation tokens.
{{KeyProviderExtension}} still leaves the onus on the caller of the API to
figure the right UGI, and since KMS calls are internal within DFSClient, the
user code still has to wrap the DFS calls in a doAs with the right UGI.
> 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
> Attachments: HDFS-10757.00.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: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
