Uploaded image for project: 'Hadoop Common'
  1. Hadoop Common
  2. HADOOP-12942

hadoop credential commands non-obviously use password of "none"

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.8.0, 3.0.0-alpha1
    • Component/s: security
    • Labels:
      None

      Description

      The "hadoop credential create" command, when using a jceks provider, defaults to using the value of "none" for the password that protects the jceks file. This is not obvious in the command or in documentation - to users or to other hadoop developers - and leads to jceks files that essentially are not protected.

      In this example, I'm adding a credential entry with name of "foo" and a value specified by the password entered:

      # hadoop credential create foo -provider localjceks://file/bar.jceks
      Enter password: 
      Enter password again: 
      foo has been successfully created.
      org.apache.hadoop.security.alias.LocalJavaKeyStoreProvider has been updated.
      

      However, the password that protects the file bar.jceks is "none", and there is no obvious way to change that. The practical way of supplying the password at this time is something akin to

      HADOOP_CREDSTORE_PASSWORD=credpass hadoop credential create --provider ...
      

      That is, stuffing HADOOP_CREDSTORE_PASSWORD into the environment of the command.

      This is more than a documentation issue. I believe that the password ought to be required. We have three implementations at this point, the two JavaKeystore ones and the UserCredential. The latter is "transient" which does not make sense to use in this context. The former need some sort of password, and it's relatively easy to envision that any non-transient implementation would need a mechanism by which to protect the store that it's creating.

      The implementation gets interesting because the password in the AbstractJavaKeyStoreProvider is determined in the constructor, and changing it after the fact would get messy. So this probably means that the CredentialProviderFactory should have another factory method like the first that additionally takes the password, and an additional constructor exist in all the implementations that takes the password.

      Then we just ask for the password in getCredentialProvider() and that gets passed down to via the factory to the implementation. The code does have logic in the factory to try multiple providers, but I don't really see how multiple providers would be rationaly be used in the command shell context.

      This issue was brought to light when a user stored credentials for a Sqoop action in Oozie; upon trying to figure out where the password was coming from we discovered it to be the default value of "none".

        Attachments

        1. HADOOP-12942.008.patch
          60 kB
          Mike Yoder
        2. HADOOP-12942.007.patch
          60 kB
          Mike Yoder
        3. HADOOP-12942.006.patch
          60 kB
          Mike Yoder
        4. HADOOP-12942.005.patch
          59 kB
          Mike Yoder
        5. HADOOP-12942.004.patch
          52 kB
          Mike Yoder
        6. HADOOP-12942.003.patch
          52 kB
          Mike Yoder
        7. HADOOP-12942.002.patch
          48 kB
          Mike Yoder
        8. HADOOP-12942.001.patch
          40 kB
          Mike Yoder

          Issue Links

            Activity

              People

              • Assignee:
                yoderme Mike Yoder
                Reporter:
                yoderme Mike Yoder
              • Votes:
                0 Vote for this issue
                Watchers:
                12 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: