hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Larry McCay (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-15325) Add an option to make Configuration.getPassword() not to fallback to read passwords from configuration.
Date Mon, 26 Mar 2018 22:53:00 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-15325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16414715#comment-16414715

Larry McCay commented on HADOOP-15325:

[~shv] - It took me a few mins to understand your perspective.

I think that you are viewing the use of getPassword as a mechanism only to be used for old
passwords that used to be stored in configuration and that any new ones should use the credential
provider API directly instead.

My view was that Configuration.getPassword is a nice convenient utility for accessing passwords
that may be stored physically in the config file or elsewhere securely via credential provider

I think both perspectives are probably valid but it seems somewhat unreasonable to make code
that may already be acquiring passwords through getPassword use a different mechanism just
because the passwords are newer and don't need backward compatibility.

I can see a list of property names that allow clear text storage for backward compatibility
or other reasons being an easy way to:
 * limit newer properties to only secure storage
 * allow new deployments rather than upgrades to turn off clear text storage completely
 * migrate to no clear text over time

Codifying this deployment specific behavior to make the decisions for them seems too inflexible.

Considering that we already have a configurable fallback behavior, extending this to treat
some properties differently from a deployment consideration seems to make sense to me and
would allow you to achieve exactly the behavior that you describe without making the decision
for others.


 * @see
 * <a href="\{@docRoot}/../hadoop-project-dist/hadoop-common/core-default.xml">
 * core-default.xml</a>
 public static final boolean


The above is used in the getPasswordFromConfig method:


 * Fallback to clear text passwords in configuration.
 * @param name
 * @return clear text password or null
 protected char[] getPasswordFromConfig(String name) {
 char[] pass = null;
 if (getBoolean(CredentialProvider.CLEAR_TEXT_FALLBACK,
  String passStr = get(name);
  if (passStr != null) {
    pass = passStr.toCharArray();
 return pass;


Check a property name list after the overall fallback enabled check and you are good to go.

We may want to have some special values like ALL|NONE and also allow for a list of property
names that don't allow fallback.

Default to ALL for current behavior. Very strict environments can set it to NONE and others
can choose the new properties vs old properties approach or whatever they like.

> Add an option to make Configuration.getPassword() not to fallback to read passwords from
> -------------------------------------------------------------------------------------------------------
>                 Key: HADOOP-15325
>                 URL: https://issues.apache.org/jira/browse/HADOOP-15325
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: conf
>    Affects Versions: 2.6.0
>            Reporter: Wei-Chiu Chuang
>            Assignee: Zsolt Venczel
>            Priority: Major
> HADOOP-10607 added a public API Configuration.getPassword() which reads passwords from
credential provider and then falls back to reading from configuration if one is not available.
> This API has been used throughout Hadoop codebase and downstream applications. It is
understandable for old password configuration keys to fallback to configuration to maintain
backward compatibility. But for new configuration passwords that don't have legacy, there
should be an option to _not_ fallback, because storing passwords in configuration is considered
a bad security practice.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org

View raw message