[
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/o...@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/o...@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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
