[
https://issues.apache.org/jira/browse/HDFS-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15429781#comment-15429781
]
Arun Suresh edited comment on HDFS-10757 at 8/21/16 4:21 PM:
-------------------------------------------------------------
bq. 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.
[~jnp], I agree with you. I also feel maybe the ugi should be setup outside of
the KMSCSP. This would also simplify the code. We could
# either modify the apis to include a ugi argument and the caller should ensure
the ugi has the credentials (This would be equivalent to probably documenting
somewhere that the client has to ensure that the keyprovider apis are always
called inside a ugi.doAs())
# Maybe create a new {{KeyProviderExtension}} implementation that takes an
existing KeyProvider, and a ugi and invokes all the keyprovider's API via the
the provided ugi.doAs() context.
Option 2 might actually be easier to implement.
Thoughts ?
was (Author: asuresh):
bq. 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.
[~jnp], I agree with you. I also feel maybe the ugi should be setup outside of
the KMSCSP. This would also simplify the code. We could
# either modify the apis to include a ugi argument and the caller should ensure
the ugi has the credentials (This would be equivalent to probably documenting
somewhere that the client has to ensure that the keyprovider apis are always
called inside a ugi.doAs())
# Maybe create a new {{KeyProviderExtension}} implementation that takes an
existing KeyProvider, and a ugi and invokes all the keyprovider's API via the
the provided ugi.doAs() context.
Option 2 might actually be easier to implement.
> 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
>
> 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]
