You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Eric Yang (JIRA)" <ji...@apache.org> on 2019/05/10 21:59:00 UTC
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation
in Hadoop does not accept principals with more than two components
[ https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837459#comment-16837459 ]
Eric Yang edited comment on HADOOP-16214 at 5/10/19 9:58 PM:
-------------------------------------------------------------
{quote}The auth_to_local rules are and always have served as a whitelist for authorization.{quote}
In [HADOOP-16023|https://issues.apache.org/jira/browse/HADOOP-16023?focusedCommentId=16737461&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16737461], [~bolke] has stated that system auth_to_local rules do not necessarily need to map to an existing user. This is true behavior of MIT Kerberos. While I appreciate your zealous style to defend existing code, but it is not the only way for authorization to work. I believe the current patch will work as it was backward compatible, and please do point out, if it is not backward compatible. We don't need to debate right way of using auth_to_local here because HADOOP-15996 has already been review and committed. [~lmccay@apache.org] has also ask you to review, which you did not have a comment. Now the issue is support multiple components for MIT Kerberos behavior. Do you see any bug in the patch that should be addressed other than the philosophical view difference?
was (Author: eyang):
{quote}The auth_to_local rules are and always have served as a whitelist for authorization.{quote}
In [HADOOP-16023|https://issues.apache.org/jira/browse/HADOOP-16023?focusedCommentId=16737461&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16737461], [~bolke] has stated that system auth_to_local rules do not necessarily need to map to an existing user. This is true behavior of MIT Kerberos. While I appreciate your zealous style to defend existing code, but it is not the only way for authorization to work. I believe the current patch will work as it was backward compatible, and please do point out, if it is not backward compatible. We don't need to debate HADOOP-16023 here because that has already been review and committed. Now the issue is support multiple components for MIT Kerberos behavior. Do you see any bug in the patch that should be addressed other than the philosophical view difference?
> Kerberos name implementation in Hadoop does not accept principals with more than two components
> -----------------------------------------------------------------------------------------------
>
> Key: HADOOP-16214
> URL: https://issues.apache.org/jira/browse/HADOOP-16214
> Project: Hadoop Common
> Issue Type: Bug
> Components: auth
> Reporter: Issac Buenrostro
> Priority: Major
> Attachments: Add-service-freeipa.png, HADOOP-16214.001.patch, HADOOP-16214.002.patch, HADOOP-16214.003.patch, HADOOP-16214.004.patch, HADOOP-16214.005.patch, HADOOP-16214.006.patch, HADOOP-16214.007.patch, HADOOP-16214.008.patch, HADOOP-16214.009.patch, HADOOP-16214.010.patch, HADOOP-16214.011.patch, HADOOP-16214.012.patch, HADOOP-16214.013.patch
>
>
> org.apache.hadoop.security.authentication.util.KerberosName is in charge of converting a Kerberos principal to a user name in Hadoop for all of the services requiring authentication.
> Although the Kerberos spec ([https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-user/What-is-a-Kerberos-Principal_003f.html]) allows for an arbitrary number of components in the principal, the Hadoop implementation will throw a "Malformed Kerberos name:" error if the principal has more than two components (because the regex can only read serviceName and hostName).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org