[
https://issues.apache.org/jira/browse/HDFS-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480234#comment-13480234
]
Ahad Rana commented on HDFS-4081:
---------------------------------
Hi Owen,
Upon further thought, perhaps it is best just to fix the canonical name
issue (a) and leave the DFS_NAMENODE_USER_NAME_KEY as it is (a single key).
It seems that the NN and everybody else (clients) should be able to use
the same consistent principal naming scheme to login as the hdfs user.
Perhaps this was the intention all along. This does beg the question as to
why there is a need for a DFS_SECONDARY_NAMENODE_USER_NAME_KEY, as the 2NN
is basically a client of the NN ? Also, what is your recommended policy
with regards to hdfs principal names ? Should they be host qualified or not
? The host qualified scheme makes a lot of sense when you are distributing
keytabs to each host in the network, but it seems a bit inconvenient that
you cannot mix the two forms, especially in the case of an admin (for
example) that would like to use password auth to get an HDFS TGT for the
purposes of using a tool like DFSAdmin.
Thanks,
Ahad.
> NamenodeProtocol and other Secure Protocols should use different config keys
> for serverPrincipal and clientPrincipal KerberosInfo components
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-4081
> URL: https://issues.apache.org/jira/browse/HDFS-4081
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: security
> Affects Versions: 2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.0.3-alpha
> Reporter: Ahad Rana
>
> The Namenode protocol (NamenodeProtocol.java) defines the same config key,
> dfs.namenode.kerberos.principal, for both ServerPrincipal and ClientPrincipal
> components of the KerberosInfo data structure. This overloads the meaning of
> the dfs.namenode.kerberos.principal config key. This key can be used to
> define the namenode's principal during startup, but in the client case, it is
> used by ServiceAuthorizationManager.authorize to create a principal name
> given an incoming client's ip address. If you explicitly set the principal
> name for the namenode in the Config using this key, it then breaks
> ServiceAuthorizationManager.authorize, because it expects this same value to
> contain a Kerberos principal name pattern NOT an explicit name.
> The solve this issue, the ServerPrincipal and ClientPrincipal components of
> the NamenodeProtocol should each be assigned unique Config keys.
--
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
