[
https://issues.apache.org/jira/browse/HDFS-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479692#comment-13479692
]
Aaron T. Myers commented on HDFS-2264:
--------------------------------------
Hi Jitendra, I think that long term it may make sense to extensively change the
protocol authorization system to support multiple expected client principal
names and/or groups, but a change like that seems like overkill to address this
particular issue.
I think that being able to configure multiple expected client principal names
in the annotation still doesn't address the issue of the balancer, which could
conceivably be run from any node in the cluster. All that should be required to
run the balancer, and hence access this interface, is super user privileges,
hence my suggestion to remove the clientPrincipal annotation entirely from the
NamenodeProtocol, and just ensure that all the operations check for super user
privileges. Would you be OK with that solution for this particular issue?
> 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
