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] [Commented] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
Date Thu, 11 Apr 2019 23:09:00 GMT

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

Eric Yang commented on HADOOP-16214:
------------------------------------

{quote}How to do this with no risk of incompatibility?

Extend the existing regexp to accept not only 0-1 extra components: service(/component)? but
n-many components: service(/component)*.
Restrict the DEFAULT rule to matching 1-2 components so using more components requires specific
configuration.{quote}

Kerberos has been around much longer than Hadoop, and there are basic principals that should
not be compromised because Hadoop was written incorrectly.  Hadoop borrowed auth_to_local
concept from MIT Kerberos, then users have rights to expect the behavior should follow MIT
Kerberos behavior as closely as possible.  I tried to write a regex to cover all possible
combinations, but I realized that I was just wasting my own time.  This is the reason that
I end up using JDK's KerberosPrincipal to parse the name for validation to reduce code maintenance.
 This should confirm no risk of incompatibility because we are one step closer to being compatible
with Kerberos.

MIT Kerberos DEFAULT rule states:
{quote}The principal name will be used as the local user name. If the principal has more than
one component or is not in the default realm, this rule is not applicable and the conversion
will fail.{quote}

In TestKerberosName#testAntiPatterns, there is one that verifies owen/owen/owe@FOO.COM isn't
applied by default rule.  The new patch works in the same behavior as MIT Kerberos.  This
is working as expected.  This confirms no risk of incompatibility because we are one step
closer to being compatible with Kerberos.

If we are more compatible to Kerberos standard, this should nullified any doubts and stop
incompatibility rumor from spreading.

> 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