[
https://issues.apache.org/jira/browse/HADOOP-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013872#comment-13013872
]
Todd Lipcon commented on HADOOP-7215:
-------------------------------------
Hi Suresh. This seems like a reasonable solution. Maybe we can also check the
kerberos info on the protocol interface, and if there's no clientPrincipal set,
we can skip all of this? My thinking is that we want to avoid the reverse DNS
lookups for the common case of user->cluster communications where no
clientPrincipal annotation is present.
> RPC clients must connect over a network interface corresponding to the host
> name in the client's kerberos principal key
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-7215
> URL: https://issues.apache.org/jira/browse/HADOOP-7215
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
> Fix For: 0.20.203.0, 0.23.0
>
> Attachments: HADOOP-7215.trunk.patch
>
>
> HDFS-7104 introduced a change where RPC server matches client's hostname with
> the hostname specified in the client's Kerberos principal name. RPC client
> binds the socket to a random local address, which might not match the
> hostname specified in the principal name. This results authorization failure
> of the client at the server.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
