[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[
https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837459#comment-16837459
]
Eric Yang edited comment on HADOOP-16214 at 5/10/19 9:58 PM:
-
{quote}The auth_to_local rules are and always have served as a whitelist for
authorization.{quote}
In
[HADOOP-16023|https://issues.apache.org/jira/browse/HADOOP-16023?focusedCommentId=16737461=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16737461],
[~bolke] has stated that system auth_to_local rules do not necessarily need to
map to an existing user. This is true behavior of MIT Kerberos. While I
appreciate your zealous style to defend existing code, but it is not the only
way for authorization to work. I believe the current patch will work as it was
backward compatible, and please do point out, if it is not backward compatible.
We don't need to debate right way of using auth_to_local here because
HADOOP-15996 has already been review and committed. [~lmc...@apache.org] has
also ask you to review, which you did not have a comment. Now the issue is
support multiple components for MIT Kerberos behavior. Do you see any bug in
the patch that should be addressed other than the philosophical view
difference?
was (Author: eyang):
{quote}The auth_to_local rules are and always have served as a whitelist for
authorization.{quote}
In
[HADOOP-16023|https://issues.apache.org/jira/browse/HADOOP-16023?focusedCommentId=16737461=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16737461],
[~bolke] has stated that system auth_to_local rules do not necessarily need to
map to an existing user. This is true behavior of MIT Kerberos. While I
appreciate your zealous style to defend existing code, but it is not the only
way for authorization to work. I believe the current patch will work as it was
backward compatible, and please do point out, if it is not backward compatible.
We don't need to debate HADOOP-16023 here because that has already been review
and committed. Now the issue is support multiple components for MIT Kerberos
behavior. Do you see any bug in the patch that should be addressed other than
the philosophical view difference?
> 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: Add-service-freeipa.png, 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, HADOOP-16214.009.patch, HADOOP-16214.010.patch,
> HADOOP-16214.011.patch, HADOOP-16214.012.patch, HADOOP-16214.013.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
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[
https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827192#comment-16827192
]
Eric Yang edited comment on HADOOP-16214 at 4/26/19 6:42 PM:
-
[~ibuenros] {quote}Is it the case that adding more components to the principal
will prevent host specific principals to verify matching host?{quote}
Yes, this is the behavior of my patches and conforming to RFC1510 NT-SRV-XHST
pattern. Where Daryn's patch will exact hostname from component 2, if the
principal has more components, this allows the principal
@ to act as service principal.
Microsoft has recently added more format to [AD supported service principal
name
format|https://docs.microsoft.com/en-us/windows/desktop/ad/name-formats-for-unique-spns#replicable-services].
Daryn's patch is not entirely accurate, but can work in most happy path.
{quote}Just to clarify, what do you mean by "more than 2 components don't
become service principal"?{quote}
In my version, /@ is service principal.
//@ does not become service principal. This is
because FreeIPA and MIT Kerberos don't consider those as service principals.
was (Author: eyang):
[~ibuenros] {quote}Is it the case that adding more components to the principal
will prevent host specific principals to verify matching host?{quote}
Yes, this is the behavior of my patches and conforming to RFC1510 NT-SRV-XHST
pattern. Where Daryn's patch will exact hostname from component 2, if the
principal has more components, this allows the principal
@ to act as service principal.
Microsoft has recently added more format to [AD supported service principal
name
format|https://docs.microsoft.com/en-us/windows/desktop/ad/name-formats-for-unique-spns#replicable-services].
Daryn's patch is not entirely accurate, but can work in most happy path.
{quote}Just to clarify, what do you mean by "more than 2 components don't
become service principal"?{quote}
In my version, /@ is service principal.
//@ does not become service principal. This is
because FreeIPA and classic Kerberos don't consider those as service principals.
> 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: Add-service-freeipa.png, 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, HADOOP-16214.009.patch, HADOOP-16214.010.patch,
> HADOOP-16214.011.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
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[
https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827192#comment-16827192
]
Eric Yang edited comment on HADOOP-16214 at 4/26/19 6:41 PM:
-
[~ibuenros] {quote}Is it the case that adding more components to the principal
will prevent host specific principals to verify matching host?{quote}
Yes, this is the behavior of my patches and conforming to RFC1510 NT-SRV-XHST
pattern. Where Daryn's patch will exact hostname from component 2, if the
principal has more components, this allows the principal
@ to act as service principal.
Microsoft has recently added more format to [AD supported service principal
name
format|https://docs.microsoft.com/en-us/windows/desktop/ad/name-formats-for-unique-spns#replicable-services].
Daryn's patch is not entirely accurate, but can work in most happy path.
{quote}Just to clarify, what do you mean by "more than 2 components don't
become service principal"?{quote}
In my version, /@ is service principal.
//@ does not become service principal. This is
because FreeIPA and classic Kerberos don't consider those as service principals.
was (Author: eyang):
[~ibuenros] {quote}Is it the case that adding more components to the principal
will prevent host specific principals to verify matching host?{quote}
Yes, this is the behavior of my patches and conforming to RFC1510 NT-SRV-XHST
pattern. Where Daryn's patch will exact hostname from component 2, if the
principal has more components, this allows the principal
@ to act as service principal.
Microsoft has recently added more format to [AD supported service principal
name
format|https://docs.microsoft.com/en-us/windows/desktop/ad/name-formats-for-unique-spns#replicable-services].
Daryn's patch is not entirely accurate, but can work in most happy path.
> 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: Add-service-freeipa.png, 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, HADOOP-16214.009.patch, HADOOP-16214.010.patch,
> HADOOP-16214.011.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
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[
https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827192#comment-16827192
]
Eric Yang edited comment on HADOOP-16214 at 4/26/19 6:36 PM:
-
[~ibuenros] {quote}Is it the case that adding more components to the principal
will prevent host specific principals to verify matching host?{quote}
Yes, this is the behavior of my patches and conforming to RFC1510 NT-SRV-XHST
pattern. Where Daryn's patch will exact hostname from component 2, if the
principal has more components, this allows the principal
@ to act as service principal.
Microsoft has recently added more format to [AD supported service principal
name
format|https://docs.microsoft.com/en-us/windows/desktop/ad/name-formats-for-unique-spns#replicable-services].
Daryn's patch is not entirely accurate, but can work in most happy path.
was (Author: eyang):
[~ibuenros] {quote}Is it the case that adding more components to the principal
will prevent host specific principals to verify matching host?{quote}
Yes, this is the behavior of my patches and conforming to RFC1510 NT-SRV-XHST
pattern. Where Daryn's patch will exact hostname from component 2, if the
principal has more components, this allows the principal
//@ to act as service principal.
> 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: Add-service-freeipa.png, 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, HADOOP-16214.009.patch, HADOOP-16214.010.patch,
> HADOOP-16214.011.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
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[
https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822180#comment-16822180
]
Erik Krogen edited comment on HADOOP-16214 at 4/19/19 8:51 PM:
---
To give more context on our use case, we have the need for more fine-grained
identity management than a simple username. For example, for the purposes of
ensuring regulatory compliance, we have the need for the behavior of systems to
vary based not just on the simple account name, but also on the specific use
case. This information, as it is closely tied to permissioning, is being
embedded in the identity of the executing application. From a core Hadoop
perspective, it is ok for permissions to be applied only against {{user}}, but
other components may treat the identity differently depending on these
additional identity data embedded in the principal.
was (Author: xkrogen):
To give more context on our use case, we have the need for more fine-grained
identity management than a simple username. For example, for the purposes of
ensuring regulatory compliance, we have the need for the behavior of systems to
vary based not just on the simple account name, but also on the specific use
case. This information, as it is closely tied to permissioning, is being
embedded in the identity of the executing application. From a core Hadoop
perspective, it is ok for permissions to be applied only against {{user}}, but
other components may treat the identity differently depending on these
additional components embedded in the principal.
> 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,
> HADOOP-16214.009.patch, HADOOP-16214.010.patch, HADOOP-16214.011.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
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[ https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815640#comment-16815640 ] Eric Yang edited comment on HADOOP-16214 at 4/18/19 1:03 AM: - [~daryn] I think I overlooked the result of testing regex in patch 9 incorrectly. My apologies. Bad inputs will indeed get rejected by your patch. A couple problems in patch 9: # Patch does not apply correctly, there is previous state that you may have committed to base on patch 8 commit. # Patch will return component 2 as hostname regardless of how many components are in the principal name. This is different from RFC1510 spec. # KerberosName does not apply hostname format check, and given anything in component two as hostname. This will be inaccurate, given a short name like "admin" may lead to host of multiple destinations that are not relevant to the intended principal. # In previous patches, it makes sure that component 2 is a FQDN format before consider it as a hostname. # Changed TestKerberosName#testAntiPatterns test case into a for loop for 1 times, it runs with 66 microseconds vs 75 microseconds (patch 8) per run. (correction, error in my pervious test procedure) # improved toString performance, but the output is not the same format as before. # a/@EXAMPLE.COM is legit kerberos principal. Patch 8 handles this correctly and it does not mark this as a host principal. Patch 9 does not. What can be better in patch 8: # Clean up serviceName to be name like in patch 9 to make variable less confusing. # Patch 8 does not check component 2 for simple security for hostname format. Performance wise, patch 8 is likely to take less time to execute. Although condition block looks big, the actual parsing without regex is much faster. 1 runs of testAntiPattern took 0.75 second, each iteration is 75 micro seconds. I could not repeat the same test for patch 9. was (Author: eyang): [~daryn] I think I overlooked the result of testing regex in patch 9 incorrectly. My apologies. Bad inputs will indeed get rejected by your patch. A couple problems in patch 9: # Patch does not apply correctly, there is previous state that you may have committed to base on patch 8 commit. # Patch will return component 2 as hostname regardless of how many components are in the principal name. This is different from RFC1510 spec. # KerberosName does not apply hostname format check, and given anything in component two as hostname. This will be inaccurate, given a short name like "admin" may lead to host of multiple destinations that are not relevant to the intended principal. # In previous patches, it makes sure that component 2 is a FQDN format before consider it as a hostname. # Changed TestKerberosName#testAntiPatterns test case into a for loop for 1 times, it failed to run. It looks like internal states are inconsistent. # improved toString performance, but the output is not the same format as before. # a/@EXAMPLE.COM is legit kerberos principal. Patch 8 handles this correctly and it does not mark this as a host principal. Patch 9 does not. What can be better in patch 8: # Clean up serviceName to be name like in patch 9 to make variable less confusing. # Patch 8 does not check component 2 for simple security for hostname format. Performance wise, patch 8 is likely to take less time to execute. Although condition block looks big, the actual parsing without regex is much faster. 1 runs of testAntiPattern took 0.75 second, each iteration is 75 micro seconds. I could not repeat the same test for patch 9. > 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, > HADOOP-16214.009.patch, HADOOP-16214.010.patch, HADOOP-16214.011.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
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[ https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819548#comment-16819548 ] Eric Yang edited comment on HADOOP-16214 at 4/16/19 10:51 PM: -- [~daryn] daryn/@REALM and daryn/ipv6-host@REALM are legal principals. They are not regression, but should have been allowed. As long as hostname field is not populated, they don't introduce security problems to Hadoop. DEFAULT rule does not apply to multiple components principal as stated by Kerberos man page. If you are referring to using auth_to_local as firewall rules to fend off users as regression, I have warned you before that auth_to_local is a utility function, not a firewall rule. What happen to people that have FreeIPA installed can able to resolve id user//clust...@example.com at OS level? Hadoop rule mechanism implementation can only map this user to another name that has potential of conflict instead of respect hierarchical user namespace. Proxy user ACL was designed for the ACL purpose, and you did not listen. This is the reason that we have to circle back to CVE discussion for Hadoop DEFAULT rule because you are defending against your own wrong idea. Real enterprises have been running kerberos for three decades, and there are schema built on top of Kerberos conventions. Without fixing those incompatibilities, it prevents Hadoop to work in real enterprises. Please don't take this personal. We are trying to fix problems here, please keep it civil. was (Author: eyang): [~daryn] daryn/@REALM and daryn/ipv6-host@REALM are legal principals. They are not regression, but should have been allowed. As long as hostname field is not populated, they don't introduce security problems to Hadoop. DEFAULT rule does not apply to multiple components principal as stated by Kerberos man page. If you are referring to using auth_to_local as firewall rules to fend off users as regression, I have warned you before that auth_to_local is a utility function, not a firewall rule. What happen to people that have FreeIPA installed can able to resolve id user//clust...@example.com at OS level? Hadoop rule mechanism implementation can only map this user to another name that has potential of conflict instead of respect hierarchical user namespace. Proxy user ACL was designed for the ACL purpose, and you did not listen. This is the reason that we have to circle back to CVE discussion for Hadoop DEFAULT rule because you are defending against wrong idea. Real enterprises have been running kerberos for three decades, and there are schema built on top of Kerberos conventions. Without fixing those incompatibilities, it prevents Hadoop to work in real enterprises. Please don't take this personal. We are trying to fix problems here, please keep it civil. > 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, > HADOOP-16214.009.patch, HADOOP-16214.010.patch, HADOOP-16214.011.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
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[ https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819548#comment-16819548 ] Eric Yang edited comment on HADOOP-16214 at 4/16/19 10:37 PM: -- [~daryn] daryn/@REALM and daryn/ipv6-host@REALM are legal principals. They are not regression, but should have been allowed. As long as hostname field is not populated, they don't introduce security problems to Hadoop. DEFAULT rule does not apply to multiple components principal as stated by Kerberos man page. If you are referring to using auth_to_local as firewall rules to fend off users as regression, I have warned you before that auth_to_local is a utility function, not a firewall rule. What happen to people that have FreeIPA installed can able to resolve id user//clust...@example.com at OS level? Hadoop rule mechanism implementation can only map this user to another name that has potential of conflict instead of respect hierarchical user namespace. Proxy user ACL was designed for the ACL purpose, and you did not listen. This is the reason that we have to circle back to CVE discussion for Hadoop DEFAULT rule because you are defending against wrong idea. Real enterprises have been running kerberos for three decades, and there are schema built on top of Kerberos conventions. Without fixing those incompatibilities, it prevents Hadoop to work in real enterprises. Please don't take this personal. We are trying to fix problems here, please keep it civil. was (Author: eyang): [~daryn] daryn/@REALM and daryn/ipv6-host@REALM are legal principals. They are not regression, but should have been allowed. As long as hostname field is not populated, they don't introduce security problems to Hadoop. DEFAULT rule does not apply to multiple components principal as stated by Kerberos man page. If you are referring to using auth_to_local as firewall rules to fend off users as regression, I have warned you before that auth_to_local is a utility function, not a firewall rule. What happen to people that have FreeIPA installed can able to resolve id user//clust...@example.com at OS level? Hadoop rule mechanism implementation can only map this user to another name that has potential of conflict instead of respect hierarchical user namespace. Proxy user echo was designed for the ACL purpose, and you did not listen. This is the reason that we have to circle back to CVE discussion for Hadoop DEFAULT rule because you are defending against wrong idea. Real enterprises have been running kerberos for three decades, and there are schema built on top of Kerberos conventions. Without fixing those incompatibilities, it prevents Hadoop to work in real enterprises. Please don't take this personal. We are trying to fix problems here, please keep it civil. > 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, > HADOOP-16214.009.patch, HADOOP-16214.010.patch, HADOOP-16214.011.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
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[ https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819548#comment-16819548 ] Eric Yang edited comment on HADOOP-16214 at 4/16/19 10:36 PM: -- [~daryn] daryn/@REALM and daryn/ipv6-host@REALM are legal principals. They are not regression, but should have been allowed. As long as hostname field is not populated, they don't introduce security problems to Hadoop. DEFAULT rule does not apply to multiple components principal as stated by Kerberos man page. If you are referring to using auth_to_local as firewall rules to fend off users as regression, I have warned you before that auth_to_local is a utility function, not a firewall rule. What happen to people that have FreeIPA installed can able to resolve id user//clust...@example.com at OS level? Hadoop rule mechanism implementation can only map this user to another name that has potential of conflict instead of respect hierarchical user namespace. Proxy user echo was designed for the ACL purpose, and you did not listen. This is the reason that we have to circle back to CVE discussion for Hadoop DEFAULT rule because you are defending against wrong idea. Real enterprises have been running kerberos for three decades, and there are schema built on top of Kerberos conventions. Without fixing those incompatibilities, it prevents Hadoop to work in real enterprises. Please don't take this personal. We are trying to fix problems here, please keep it civil. was (Author: eyang): [~daryn] daryn/@REALM and daryn/ipv6-host@REALM are legal principals. They are not regression, but should have been allowed. As long as hostname field is not populated, they don't introduce security problems to Hadoop. DEFAULT rule does not apply to multiple components principal as stated by Kerberos man page. I don't understand your statement of regression. Real enterprises have been running kerberos for three decades, and there are schema built on top of Kerberos conventions. Without fixing those incompatibilities, it prevents Hadoop to work in real enterprises. Please don't take this personal. We are trying to fix problem here, please keep it civil. > 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, > HADOOP-16214.009.patch, HADOOP-16214.010.patch, HADOOP-16214.011.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
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[ https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819298#comment-16819298 ] Eric Yang edited comment on HADOOP-16214 at 4/16/19 5:23 PM: - [~xkrogen] Daryn originally stated two incompatibility. # The check bad translation owen/owen/o...@foo.com was removed. This is what this feature tries to support. Therefore, removing that bad name from test case is proper. Patch 9 version converted from checkBadName to checkBadTranslation. This is only benefits his own proposal of using auth_to_local as firewall rules to prevent unauthorized users from getting into secure cluster. This is not retaining backward compatibility, but benefit for his own agenda. # The second incompatibility was stated that the simple security, it should strip and parse the first component for names that containing multiple "/". This is a security hole that losing hierarchical from user identity will result in name conflict. I don't express a opinion on the second incompatibility and have adjusted patch 11 to restore original behavior. This security issue can be tackled in another issue. I think patch 11 has address his concerns and ask him to review. The existing code looks innocent, but it is dangerous. Daryn started this conversation without knowing the details that KerberosName class is used by both Kerberos security and simple security. *Simple security does not apply auth_to_local rule*. Believing in Daryn's statement that secure client can inter-operate with insecure server, would be a foolish mistake. This puts clusters at risk. It provide false sense of security using backward compatibility as excuse. Are you ok with Daryn slip in his own Agenda in the patch and not maintain backward compatibility to test cases that he advocate to keep? If we do that, then the test cases only regress further from Kerberos compliance. We will wonder why did we allow insecure code to run in secure cluster and not apply auth_to_local firewall. Wait a minute? That was never in Kerberos spec. Who came up with that idea to shoot himself on the foot, [~daryn]? was (Author: eyang): [~xkrogen] Daryn originally stated two incompatibility. # The check bad translation owen/owen/o...@foo.com was removed. This is what this feature tries to support. Therefore, removing that bad name from test case is proper. Patch 9 version converted from checkBadName to checkBadTranslation. This is only benefits his own proposal of using auth_to_local as firewall rules to prevent unauthorized users from getting into secure cluster. This is not retaining backward compatibility, but benefit for his own agenda. # The second incompatibility was stated that the simple security, it should strip and parse the first component for names that containing multiple "/". This is a security hole that losing hierarchical from user identity will result in name conflict. I don't express a opinion on the second incompatibility and have adjusted patch 11 to restore original behavior. This security issue can be tackled in another issue. I think patch 11 has address his concerns and ask him to review. The existing code looks innocent, but it is dangerous. Daryn started this conversation without knowing the details that KerberosName class is used by both Kerberos security and simple security. *Simple security does not apply auth_to_local rule*. Believing in Daryn's statement that Security client can inter-operate with insecure server, would be a foolish mistake. This puts clusters at risk. It provide false sense of security using backward compatibility as excuse. Are you ok with Daryn slip in his own Agenda in the patch and not maintain backward compatibility to test cases that he advocate to keep? If we do that, then the test cases only regress further from Kerberos compliance. We will wonder why did we allow insecure code to run in secure cluster and not apply auth_to_local firewall. Wait a minute? That was never in Kerberos spec. Who came up with that idea to shoot himself on the foot, [~daryn]? > 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, > HADOOP-16214.009.patch, HADOOP-16214.010.patch, HADOOP-16214.011.patch > > >
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[
https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[
https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[
https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Comment Edited] (HADOOP-16214) Kerberos name implementation in Hadoop does not accept principals with more than two components
[ https://issues.apache.org/jira/browse/HADOOP-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812909#comment-16812909 ] Eric Yang edited comment on HADOOP-16214 at 4/9/19 1:09 AM: [~daryn] In Linux, HTTP/abc.com isn't a valid name, where HTTP/abc@example.com is. I am not sure that the code must retain the same output for the two distinct cases. The change in patch 6 is to make sure that we don't try to make an invalidate username into a valid one by not making modification to username. Patch 8 will keep the consistency for no realm case with realm case, but it may allow invalid username to become valid one. Maybe we should just throw error for HTTP/abc.com? was (Author: eyang): [~daryn] In Linux, HTTP/abc.com isn't a valid name, where HTTP/abc@example.com is. I am not sure that the code must retain the same output for the two distinct cases. The change in patch 6 is to make sure that we don't try to make an invalidate username into a valid one by not making modification to username. Patch 8 will keep the consistency for no realm case with realm case, but it may allow invalid username to become valid one. > 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
