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