Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Sat, 27 Feb 2016 21:56:18 +0000 (UTC)
From: "Larry McCay (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12944968.1456508243000.165818.1456610178077@Atlassian.JIRA>
In-Reply-To: <JIRA.12944968.1456508243000@Atlassian.JIRA>
References: <JIRA.12944968.1456508243000@Atlassian.JIRA>
 <JIRA.12944968.1456508243984@arcas>
Subject: [jira] [Updated] (HADOOP-12846) Credential Provider Recursive
 Dependencies
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HADOOP-12846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Larry McCay updated HADOOP-12846:
---------------------------------
    Status: Patch Available  (was: Open)

> Credential Provider Recursive Dependencies
> ------------------------------------------
>
>                 Key: HADOOP-12846
>                 URL: https://issues.apache.org/jira/browse/HADOOP-12846
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: Larry McCay
>            Assignee: Larry McCay
>         Attachments: HADOOP-12846-001.patch, HADOOP-12846-002.patch, HADOOP-12846-003.patch
>
>
> There are a few credential provider integration points in which the use of a certain type of provider in a certain filesystem causes a recursive infinite loop. 
> For instance, a component such as sqoop can be protecting a db password in a credential provider within the wasb/azure filesystem. Now that HADOOP-12555 has introduced the ability to protect the access keys for wasb we suddenly need access to wasb to get the database keys which initiates the attempt to get the access keys from wasb - since there is a provider path configured for sqoop.
> For such integrations, those in which it doesn't make sense to protect the access keys inside the thing that we need the keys to access, we need a solution to avoid this recursion - other than dictating what filesystems can be used by other components.
> This patch proposes the ability to scrub the configured provider path of any provider types that would be incompatible with the integration point. In other words, before calling Configuration.getPassword for the access keys to wasb, we can remove any configured providers that require access to wasb.
> This will require some regex expressions that can be used to identify the configuration of such provider uri's within the provider path parameter.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)