[ 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