[
https://issues.apache.org/jira/browse/HADOOP-12942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15212473#comment-15212473
]
Mike Yoder commented on HADOOP-12942:
-------------------------------------
I guess I didn't explain my intent to prompt the user for a password very
clearly. My (admittedly simplistic) thinking was "hey there's no password".
"We should therefore make sure there's a password."
{quote}
If we are leveraging the password-in-a-file approach then why are we going to
prompt the user for a password? It should be in the config if that is what is
going to be used.
{quote}
So if there is in fact a password in a file referred to in the config, it takes
priority and the user will never be prompted for a password. That's why the
providers' needsPassword() has to exist. We aren't doing anything new with the
password-in-a-file approach with this patch; it's has been there and continues
to be there.
{quote}
Additionally, how is the MR job going be assured to have the password to access
the keystore by this?
{quote}
They aren't - but they never were assured of this in the first place. If you're
reading from a file pointed to by the config, you're assuming that the same
config will exist in the context in which it's later used (and that the file
exists, too). If you're using an environment variable, you're assuming the
environment variable is going to exist in the future context in which it's
later used. Neither of these are guaranteed.
{quote}
If you are setting a password without it being first provisioned in the file
then you are setting them up for a credential store that can't be opened.
{quote}
There is a higher probability of that with my patch, yes. I believe this to be
better than setting the user up for unintentional insecure storage of secrets.
I don't know how to handle this better, and I'm not sure that we can since we
don't know how the cred store will be accessed in the future.
{quote}
The current behavior should find the provisioned keystore password from the
file and create the credential store appropriately with no need to prompt the
user. This is the intended behavior by design and keeps the config aligned with
the keystore password.
{quote}
I see what you're getting at, but I guess I have not felt that they are as
"aligned" as you feel they are.
So instead of prompting the user for a password, you would instead check for
either the password-in-a-file or the environment variable, and if they don't
exist, error out with a message stating that the provider couldn't find the
password and here's how to provide it?
That would achieve the same sort of goal, but it just seemed easier and a
better interface to just ask the user for the password. I suppose my patch
doesn't give the user any hints on how to set things up so future stuff could
read the keystore, though, which isn't great.
{quote}
The current behavior isn't a bug "none" is a real password
{quote}
See if I agreed with this I never would have filed this jira. :-) I feel that
it is a bug to give the user the impression that a value is being securely
stored when in fact it is not. Hardcoded "none" provides no protection.
{quote}
I also see the backward compatibility issue as a non-starter
{quote}
I view the current _interface_ as having the bug - that interface being the
non-obvious use of a password "none". As such, the interface ought to change,
and as such that means a backwards compatibility issue. But...ergh. If we must
keep the interface safe for scripts and the like... how about the following
algorithm
.
* if there are no new command line arguments
** if file or env var found
*** great, continue as before
** else
*** print a big WARNING that they are using a password of "none" and
instructions on how to set it; continue as before
* else if "-password" or "-askMeTheProviderPassword" is found on the command
line obtain the provider password, and
** if the provider _already_ has a password via file or env var, print a
WARNING that the file or env var exists, and that the user supplied password
will be ignored
** else pass the given password into the provider.
This gives us backwards compatibility, notification to the user that they're
doing something insecure, and a way to provide the password in the command
itself. Your thoughts?
> 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
>
>
> 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)
