Uploaded image for project: 'Hadoop HDFS'
  1. Hadoop HDFS
  2. HDFS-4457

WebHDFS obtains/sets delegation token service hostname using wrong config leading to issues when NN is configured with 0.0.0.0 RPC IP

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Critical
    • Resolution: Won't Fix
    • 1.1.1, 2.0.2-alpha
    • None
    • webhdfs
    • None

    Description

      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.

      Attachments

        1. HDFS_4457.patch
          6 kB
          Alejandro Abdelnur
        2. HDFS_4457.patch
          7 kB
          Alejandro Abdelnur

        Activity

          People

            tucu00 Alejandro Abdelnur
            tucu00 Alejandro Abdelnur
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: