[
https://issues.apache.org/jira/browse/HADOOP-11726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14376697#comment-14376697
]
Haohui Mai commented on HADOOP-11726:
-------------------------------------
bq. will it solve the "implementing a secure distcp application that can only
write to secure clusters" issue?
Yes. Obviously the application to verify whether the token is authentic, but it
is feasible as long as you don't swallow the error at the file system layer.
bq. For the "fix all application" approach, I found that for distcp, there is a
wildcard issue that the change has to go beyond distcp. See my latest comment
in HDFS-7036.
Just to echo my comments in HDFS-6776 (at least for the distcp use case):
bq. What can be done is to put the hack there, and to inject a corresponding
token into token cache so that the filesystem no longer need to get the DT from
the server.
https://issues.apache.org/jira/browse/HDFS-6776?focusedCommentId=14121719&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14121719
> Allow applications to access both secure and insecure clusters at the same
> time
> -------------------------------------------------------------------------------
>
> Key: HADOOP-11726
> URL: https://issues.apache.org/jira/browse/HADOOP-11726
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Haohui Mai
>
> Today there are multiple integration issues when an application
> (particularly, distcp) access both secure and insecure clusters (e.g.,
> HDFS-6776 / HDFS-7036)
> There are four use cases in this scenario:
> * Secure <-> Secure. Works.
> * Insecure <-> Insecure. Works.
> * Accessing secure clusters from insecure client. Will not work as expected.
> The insecure client won't be able to be authenticated with the secure client,
> otherwise it is a security vulnerability.
> * Accessing insecure clusters from secure client. Currently it will not work
> as the secure client won't be able to obtain a delegation token from the
> insecure cluster.
> This jira proposes to fix the last use case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
