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

Daryn Sharp commented on HDFS-4457:
-----------------------------------

As an update, Aaron & Alejandro & I had an offline conversation to educate each 
other on the requirements and issues with this change.  The next step is 
discovering how Hue is converting the {{Token}} into a {{Credentials}} for Pig.
                
> WebHDFS obtains/sets delegation token service hostname using wrong config 
> leading to issues when NN is configured with 0.0.0.0 RPC IP
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-4457
>                 URL: https://issues.apache.org/jira/browse/HDFS-4457
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: webhdfs
>    Affects Versions: 1.1.1, 2.0.2-alpha
>            Reporter: Alejandro Abdelnur
>            Assignee: Alejandro Abdelnur
>            Priority: Critical
>         Attachments: HDFS_4457.patch, HDFS_4457.patch
>
>
> If the NameNode RPC address is configured with an wildcard IP 0.0.0.0, then 
> delegationotkens are configured with 0.0.0.0 as service and this breaks 
> clients trying to use those tokens.
> Looking at NamenodeWebHdfsMethods#generateDelegationToken() the problem is 
> SecurityUtil.setTokenService(t, namenode.getHttpAddress());, tracing back 
> what is being used to resolve getHttpAddress() the NameNodeHttpServer is 
> resolving the httpAddress doing a httpAddress = new 
> InetSocketAddress(bindAddress.getAddress(), httpServer.getPort());
> , and if using "0.0.0.0" in the configuration, you get 0.0.0.0 from 
> bindAddress.getAddress().
> Normally (non webhdfs) this is not an issue because it is the responsibility 
> of the client, but in the case of WebHDFS, WebHDFS does it before returning 
> the string version of the token (it must be this way because the client may 
> not be a java client at all and cannot manipulate the DelegationToken as 
> such).
> The solution (thanks to Eric Sammer for helping figure this out) is for 
> WebHDFS to use the exacty hostname that came in the HTTP request as the 
> service to set in the delegation tokens.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to