hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Yang (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
Date Tue, 16 Apr 2019 17:24:00 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819298#comment-16819298
] 

Eric Yang edited comment on HADOOP-16214 at 4/16/19 5:23 PM:
-------------------------------------------------------------

[~xkrogen] Daryn originally stated two incompatibility.  

# The check bad translation owen/owen/owen@FOO.COM was removed.  This is what this feature
tries to support.  Therefore, removing that bad name from test case is proper.  Patch 9 version
converted from checkBadName to checkBadTranslation.  This is only benefits his own proposal
of using auth_to_local as firewall rules to prevent unauthorized users from getting into secure
cluster.  This is not retaining backward compatibility, but benefit for his own agenda.
# The second incompatibility was stated that the simple security, it should strip and parse
the first component for names that containing multiple "/".  This is a security hole that
losing hierarchical from user identity will result in name conflict.  I don't express a opinion
on the second incompatibility and have adjusted patch 11 to restore original behavior.  This
security issue can be tackled in another issue.

I think patch 11 has address his concerns and ask him to review.  The existing code looks
innocent, but it is dangerous. 
Daryn started this conversation without knowing the details that KerberosName class is used
by both Kerberos security and simple security.   *Simple security does not apply auth_to_local
rule*.  Believing in Daryn's statement that secure client can inter-operate with insecure
server, would be a foolish mistake.  This puts clusters at risk.  It provide false sense of
security using backward compatibility as excuse.  Are you ok with Daryn slip in his own Agenda
in the patch and not maintain backward compatibility to test cases that he advocate to keep?
 If we do that, then the test cases only regress further from Kerberos compliance.  We will
wonder why did we allow insecure code to run in secure cluster and not apply auth_to_local
firewall.  Wait a minute?  That was never in Kerberos spec.  Who came up with that idea to
shoot himself on the foot, [~daryn]?


was (Author: eyang):
[~xkrogen] Daryn originally stated two incompatibility.  

# The check bad translation owen/owen/owen@FOO.COM was removed.  This is what this feature
tries to support.  Therefore, removing that bad name from test case is proper.  Patch 9 version
converted from checkBadName to checkBadTranslation.  This is only benefits his own proposal
of using auth_to_local as firewall rules to prevent unauthorized users from getting into secure
cluster.  This is not retaining backward compatibility, but benefit for his own agenda.
# The second incompatibility was stated that the simple security, it should strip and parse
the first component for names that containing multiple "/".  This is a security hole that
losing hierarchical from user identity will result in name conflict.  I don't express a opinion
on the second incompatibility and have adjusted patch 11 to restore original behavior.  This
security issue can be tackled in another issue.

I think patch 11 has address his concerns and ask him to review.  The existing code looks
innocent, but it is dangerous. 
Daryn started this conversation without knowing the details that KerberosName class is used
by both Kerberos security and simple security.   *Simple security does not apply auth_to_local
rule*.  Believing in Daryn's statement that Security client can inter-operate with insecure
server, would be a foolish mistake.  This puts clusters at risk.  It provide false sense of
security using backward compatibility as excuse.  Are you ok with Daryn slip in his own Agenda
in the patch and not maintain backward compatibility to test cases that he advocate to keep?
 If we do that, then the test cases only regress further from Kerberos compliance.  We will
wonder why did we allow insecure code to run in secure cluster and not apply auth_to_local
firewall.  Wait a minute?  That was never in Kerberos spec.  Who came up with that idea to
shoot himself on the foot, [~daryn]?

> 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: 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
>
>
> 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


Mime
View raw message