hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (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 22:06:00 GMT

    [ 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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message