[
https://issues.apache.org/jira/browse/HDFS-15545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225112#comment-17225112
]
Wei-Chiu Chuang commented on HDFS-15545:
----------------------------------------
+1.
We have quite poor support and test coverage for externally managed user
credentials. Even though we can support this use case for webhdfs, I am not
certain if we support the same for HDFS (or httpfs or any other file system
implementations) and if at-rest encryption (KMS delegation token) is supported.
It would be great if we can do a more holistic study of this area.
> (S)Webhdfs will not use updated delegation tokens available in the ugi after
> the old ones expire
> ------------------------------------------------------------------------------------------------
>
> Key: HDFS-15545
> URL: https://issues.apache.org/jira/browse/HDFS-15545
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Issac Buenrostro
> Assignee: Issac Buenrostro
> Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-15545.001.patch, HDFS-15545.002.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> WebHdfsFileSystem can select a delegation token to use from the current user
> UGI. The token selection is sticky, and WebHdfsFileSystem will re-use it
> every time without searching the UGI again.
> If the previous token expires, WebHdfsFileSystem will catch the exception and
> attempt to get a new token. However, the mechanism to get a new token
> bypasses searching for one on the UGI, so even if there is external logic
> that has retrieved a new token, it is not possible to make the FileSystem use
> the new, valid token, rendering the FileSystem object unusable.
> A simple fix would allow WebHdfsFileSystem to re-search the UGI, and if it
> finds a different token than the cached one try to use it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
