[
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. [[email protected]] 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: [email protected]
For additional commands, e-mail: [email protected]
