[
https://issues.apache.org/jira/browse/HADOOP-12942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228718#comment-15228718
]
Mike Yoder commented on HADOOP-12942:
-------------------------------------
Thanks for having a look.
{quote}
WARN messages (without strict flag): read too much like ERRORs \[...] It is
perfectly legitimate to use the static/hardcoded password.
{quote}
See, here's where we disagree. Using the CredentialProvider or KeyProvider
indicates that the user cares about security. Otherwise they wouldn't use the
feature at all - for example just providing a cleartext password instead of
getting it through the CredentialProvider. So if the user cares about
security, they are going to care that the provider is actually protecting the
information.
Or to come at this a different way - I can think of no other secure system
involving a password where the use of a default hardcoded password is common.
So yeah, given my assumptions above the WARN messages are pretty severe on
purpose. It's difficult for me to fathom a (security conscious) user who, upon
learning that they were using a static hardcoded password, would say "meh".
{quote}
a provider *requires* a password
{quote}
Well, it requires a password for an attempt at secure operation.
{quote}
It would also be good to let the user know that when a custom password is
being used that it must be available to the runtime consumers of it as well.
The trick is communicating all of this without spitting out a book.
{quote}
Quite true. How about the following two new lines:
{noformat}
WARNING: The provider cannot find a password in the expected locations.
Please supply a password using one of the following two mechanisms:
o In the environment variable ...
o In a file referred to by the configuration entry ...
Please note that when this provider is used in the future, the password must
also be available to it in the same manner.
Continuing with default provider password "none"
{noformat}
{quote}
I'm not sure that the hardcoded password needs to be emitted on the command
line in order to satisfy "obviousness".
{quote}
My thinking was that the user might want to figure out what the default
password is, and so if the information is public, I might as well be helpful
right on the command line.
{quote}
I think we should take this opportunity to revisit the 700 file permissions
and change it to 600
{quote}
OK, makes me a little nervous to lump that in, but sure.
{quote}
the consolidation of some caught keystore exceptions
{quote}
There was one place I changed
{noformat}
- } catch (NoSuchAlgorithmException e) {
- throw new IOException("Can't load keystore " + getPathAsString(), e);
- } catch (CertificateException e) {
- throw new IOException("Can't load keystore " + getPathAsString(), e);
- }
{noformat}
to this
{noformat}
+ } catch (GeneralSecurityException e) {
+ throw new IOException("Can't load keystore " + getPathAsString(), e);
+ }
{noformat}
just to collapse the to dups into one.
> 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
> Attachments: HADOOP-12942.001.patch, HADOOP-12942.002.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)
