[ https://issues.apache.org/jira/browse/HADOOP-12942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15284926#comment-15284926 ]
Larry McCay commented on HADOOP-12942: -------------------------------------- Thanks, [~cnauroth]! I thought that I used to be able to do that. > hadoop credential commands non-obviously use password of "none" > --------------------------------------------------------------- > > Key: HADOOP-12942 > URL: https://issues.apache.org/jira/browse/HADOOP-12942 > Project: Hadoop Common > Issue Type: Bug > Components: security > Reporter: Mike Yoder > Assignee: Mike Yoder > Fix For: 2.8.0 > > Attachments: HADOOP-12942.001.patch, HADOOP-12942.002.patch, > HADOOP-12942.003.patch, HADOOP-12942.004.patch, HADOOP-12942.005.patch, > HADOOP-12942.006.patch, HADOOP-12942.007.patch, HADOOP-12942.008.patch > > > 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: > {noformat} > # 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. > {noformat} > 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 > {noformat} > HADOOP_CREDSTORE_PASSWORD=credpass hadoop credential create --provider ... > {noformat} > 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". -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org