[
https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16813851#comment-16813851
]
Daryn Sharp edited comment on HADOOP-16214 at 4/9/19 10:05 PM:
---------------------------------------------------------------
Let's be respectful. I'm familiar with the code.
{quote}... 3 is RFC compliant because this is a user principal. ... Therefore,
handling HTTP/abc.com/admin in serviceName is correct to ensure the components
can be parsed for auth_to_local mapping regardless this is a service principal
or user principal.
{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.
Please clarify what are the form of these non-standard principals? If the
second component is a host, then you really want my suggested option #3. It
strikes a balance in consistency of serviceName and host regardless of number
of components, and allows referencing additional components via $3, $4, etc
since it’s treated as a SPN.
{quote}However, username may handle incorrectly by splitting by "/" in Hadoop
logic in the attempt to keep both simple security and kerberos security look a
like.
{quote}
That's 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.
was (Author: daryn):
Let's be respectful. I'm familiar with the code.
bq. ... 3 is RFC compliant because this is a user principal. ... Therefore,
handling HTTP/abc.com/admin in serviceName is correct to ensure the components
can be parsed for auth_to_local mapping regardless this is a service principal
or user principal.
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.
Please clarify what are the form of these non-standard principals? If the
second component is a host, then you really want my suggested option #3. It
strikes a balance in consistency of serviceName and host regardless of number
of components, and allows referencing additional components via $3, $4, etc
since it’s treated as a SPN.
bq. However, username may handle incorrectly by splitting by "/" in Hadoop
logic in the attempt to keep both simple security and kerberos security look a
like.
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.
> 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
