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

Aaron T. Myers updated HDFS-2264:
---------------------------------

    Attachment: HDFS-2264.patch

Here's a patch which addresses the issue by removing the clientPrincipal from 
the annotation for the NamenodeProtocol and instead adds a superuser check to 
every method in the NN implemented as part of the NamenodeProtocol. I also took 
the liberty of adding a few missing checks for HA operation categories that I 
noticed.

I tested this patch by running the balancer from a different host than the NN 
on a 2 node cluster where the _HOST macro _wasn't_ being used for the NN or 
2NN, i.e. the full Kerberos principal was being specified. Everything worked as 
expected. I also confirmed that the 2NN still successfully checkpoints as 
expected.
                
> 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: namenode
>    Affects Versions: 0.23.0
>            Reporter: Aaron T. Myers
>            Assignee: Harsh J
>             Fix For: 0.24.0
>
>         Attachments: HDFS-2264.patch, 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

Reply via email to