[
https://issues.apache.org/jira/browse/HDFS-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13443610#comment-13443610
]
Aaron T. Myers commented on HDFS-2264:
--------------------------------------
Hey Jitendra, sorry for forgetting about this JIRA for so long (almost exactly
a year!)
I just encountered this issue again in a user's cluster. My new thinking is
that we should just remove the expected client principal from the
NamenodeProtocol entirely. I think this makes sense the 2NN, SBN, BN, and
balancer all potentially use this interface, so there's no single client
principal that could reasonably be expected. The balancer, in particular,
should be able to be run from any node, even one not running a daemon at all.
I think to do what I propose here all we have to do is remove the
clientPrincipal parameter from the SecurityInfo annotation on the
NamenodeProtocol, and make sure that all of the methods exposed by this
interface definitely check for super user privileges. I think most of them do,
but we should ensure that they all do.
How does this sound to you?
> NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo
> annotation
> -----------------------------------------------------------------------------------
>
> Key: HDFS-2264
> URL: https://issues.apache.org/jira/browse/HDFS-2264
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.23.0
> Reporter: Aaron T. Myers
> Assignee: Harsh J
> Fix For: 0.24.0
>
> Attachments: HDFS-2264.r1.diff
>
>
> The {{@KerberosInfo}} annotation specifies the expected server and client
> principals for a given protocol in order to look up the correct principal
> name from the config. The {{NamenodeProtocol}} has the wrong value for the
> client config key. This wasn't noticed because most setups actually use the
> same *value* for for both the NN and 2NN principals ({{hdfs/_HOST@REALM}}),
> in which the {{_HOST}} part gets replaced at run-time. This bug therefore
> only manifests itself on secure setups which explicitly specify the NN and
> 2NN principals.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
