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, 09 Apr 2019 23:12:00 GMT

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

Eric Yang edited comment on HADOOP-16214 at 4/9/19 11:11 PM:
-------------------------------------------------------------

{quote}Putting forth the argument that a 2+ component principal is really a UPN (MIT enterprise
parse option) means the principal is a single opaque component. There is no $2 or $3. The
ability to rewrite becomes limited. The ability to support host restrictions is lost. That’s
likely not what you want.{quote}

According to kerberos source code, it does parsing of each components in [a for loop|https://github.com/krb5/krb5/blob/09c9b7d6f64767429e90ad11a529e6ffa9538043/src/lib/krb5/os/localauth.c#L328],
and $2, $3 works fine.  On RedHat 7, krb5 with auth_to_local rule:

{code}
  EXAMPLE.COM = {
    admin_server = host-1
    kdc = host-1
    auth_to_local = RULE:[3:$2](b)/s/^.*$/guest/
{code}

A 3 components principal with second part matching /b/ will be translate to guest.  This works
just fine.  In addition, UPN does not have a hostname component.  We only care about hostname
component for service principal when service impersonates end user.  Multiple parts components
that does not map to RFC1510 service principal format are classified as [KRB_NT_PRINCIPAL|https://github.com/openjdk/jdk/blob/6bab0f539fba8fb441697846347597b4a0ade428/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java#L125]
by JDK.  It does not try to parse hostname of a 3 parts component principal, and the patch
follows the behavior of JDK correctly.

{quote}It's not incorrect. It supports interop between secure clients and insecure servers.
Insecure servers treats principals as principals, else as the short name used by insecure
clients.{quote}

Substring of hierarchical username format is known to cause name conflicts.  Hadoop is quite
flexible to integrate with other system.  Leaving name untouched is more preferable in case
someone extends Hadoop to interface with other system.  Our code doesn't get in the way to
chop off user identity.


was (Author: eyang):
{quote}Putting forth the argument that a 2+ component principal is really a UPN (MIT enterprise
parse option) means the principal is a single opaque component. There is no $2 or $3. The
ability to rewrite becomes limited. The ability to support host restrictions is lost. That’s
likely not what you want.{quote}

According to kerberos source code, it does parsing of each components in [a for loop|https://github.com/krb5/krb5/blob/09c9b7d6f64767429e90ad11a529e6ffa9538043/src/lib/krb5/os/localauth.c#L328],
and $2, $3 works fine.  On RedHat 7, krb5 with auth_to_local rule:

{code}
  EXAMPLE.COM = {
    admin_server = host-1
    kdc = host-1
    auth_to_local = RULE:[3:$2](b)/s/^.*$/guest/
{code}

A 3 components principal with second part matching /b/ will be translate to guest.  This works
just fine.  Please do not spread rumors, if you haven't checked all facts.  In addition, UPN
does not have a hostname component.  We only care about hostname component for service principal
when service impersonates end user.  Multiple parts components that does not map to RFC1510
service principal format are classified as [KRB_NT_PRINCIPAL|https://github.com/openjdk/jdk/blob/6bab0f539fba8fb441697846347597b4a0ade428/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java#L125]
by JDK.  It does not try to parse hostname of a 3 parts component principal, and the patch
follows the behavior of JDK correctly.

{quote}It's not incorrect. It supports interop between secure clients and insecure servers.
Insecure servers treats principals as principals, else as the short name used by insecure
clients.{quote}

Substring of hierarchical username format is known to cause name conflicts.  Hadoop is quite
flexible to integrate with other system.  Leaving name untouched is more preferable in case
someone extends Hadoop to interface with other system.  Our code doesn't get in the way to
chop off user identity.

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