[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[ https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15048358#comment-15048358 ] Hudson commented on HADOOP-12617: - FAILURE: Integrated in Hadoop-Hdfs-trunk-Java8 #678 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/678/]) HADOOP-12617. SPNEGO authentication request to non-default realm gets (mattf: rev ada9c2c410c15e95d0a21ea2941986195606aad8) * hadoop-common-project/hadoop-common/CHANGES.txt * hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestKerberosUtil.java * hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/KerberosUtil.java > SPNEGO authentication request to non-default realm gets default realm name > inserted in target server principal > -- > > Key: HADOOP-12617 > URL: https://issues.apache.org/jira/browse/HADOOP-12617 > Project: Hadoop Common > Issue Type: Bug > Components: security >Affects Versions: 2.7.1 > Environment: Java client talking to two secure clusters in different > Kerberos realms, > or talking to any secure cluster in non-default realm >Reporter: Matt Foley >Assignee: Matt Foley > Fix For: 2.8.0 > > Attachments: HADOOP-12617-branch-2.7.001.patch, > HADOOP-12617-branch-2.7.003.patch, HADOOP-12617.003.patch, > HADOOP-12617.005.patch, HADOOP-12617.006.patch, HADOOP-12617.007.patch, > HADOOP-12617.008.patch > > > Note: This is NOT a vulnerability. > In order for a single Java client to communicate with two different secure > clusters in different realms (only one of which can be the "default_realm"), > the client's krb5.conf file must specify both realms, and provide a > \[domain_realm\] section that maps cluster servers' domains to the correct > realms. With other appropriate behaviors (such as using the config from each > cluster to talk to the respective clusters, and a user principal from each > realm to talk to the respective realms), this is sufficient for most Hadoop > ecosystem clients. > But our SPNEGO using clients, such as Oozie, have a bug when it comes to > talking to a non-default realm. The default realm name gets incorrectly > inserted into the construction of the target server principal for the > non-default-realm cluster. Details and proposed solution are given in the > first comments below. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[
https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15046643#comment-15046643
]
Hadoop QA commented on HADOOP-12617:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 1s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
53s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 57s
{color} | {color:green} trunk passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 32s
{color} | {color:green} trunk passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
8s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 23s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
28s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 13s
{color} | {color:green} trunk passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} trunk passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 53s
{color} | {color:green} the patch passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m 53s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 16s
{color} | {color:green} the patch passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 9m 16s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
9s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 21s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
35s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 12s
{color} | {color:green} the patch passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 41s
{color} | {color:green} hadoop-auth in the patch passed with JDK v1.8.0_66.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m 3s
{color} | {color:green} hadoop-auth in the patch passed with JDK v1.7.0_85.
{color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 20s
{color} | {color:red} Patch generated 3 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 57m 20s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:0ca8df7 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12776272/HADOOP-12617.006.patch
|
| JIRA Issue | HADOOP-12617 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux 8ba1962ca70c 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh
|
| git revision | trunk / fc47084 |
| findbugs | v3.0.0 |
| JDK v1.7.0_85 Test Results |
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[
https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15046826#comment-15046826
]
Vinayakumar B commented on HADOOP-12617:
Thanks [~mattf] for the patch.
It looks great. [~surendrasingh] was able to verify in our cluster with the
patch with Oracle Java. It works great.
I just have one nit.
{code}System.getProperty("java.vendor").contains("IBM"){code}
You can use {{PlatformName.IBM_JAVA}} instead. Its already used in KerberosUtil.
+1 once addressed.
> SPNEGO authentication request to non-default realm gets default realm name
> inserted in target server principal
> --
>
> Key: HADOOP-12617
> URL: https://issues.apache.org/jira/browse/HADOOP-12617
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
>Affects Versions: 2.7.1
> Environment: Java client talking to two secure clusters in different
> Kerberos realms,
> or talking to any secure cluster in non-default realm
>Reporter: Matt Foley
>Assignee: Matt Foley
> Attachments: HADOOP-12617-branch-2.7.001.patch,
> HADOOP-12617.003.patch, HADOOP-12617.005.patch, HADOOP-12617.006.patch
>
>
> Note: This is NOT a vulnerability.
> In order for a single Java client to communicate with two different secure
> clusters in different realms (only one of which can be the "default_realm"),
> the client's krb5.conf file must specify both realms, and provide a
> \[domain_realm\] section that maps cluster servers' domains to the correct
> realms. With other appropriate behaviors (such as using the config from each
> cluster to talk to the respective clusters, and a user principal from each
> realm to talk to the respective realms), this is sufficient for most Hadoop
> ecosystem clients.
> But our SPNEGO using clients, such as Oozie, have a bug when it comes to
> talking to a non-default realm. The default realm name gets incorrectly
> inserted into the construction of the target server principal for the
> non-default-realm cluster. Details and proposed solution are given in the
> first comments below.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[
https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15047453#comment-15047453
]
Matt Foley commented on HADOOP-12617:
-
[~vinayrpet], thanks for the review. Agree re IBM_JAVA, have changed it.
Rather than mix usages, I also corrected two existing instances of
'System.getProperty("java.vendor").contains("IBM")', so now KerberosUtil.java
uses solely the 'IBM_JAVA' usage. I only did this in the trunk patch, not for
maintenance branches, since it is a cleanup not a bug fix.
Will run it thru the Hadoop QA robot once more, then I will commit it per your
+1.
> SPNEGO authentication request to non-default realm gets default realm name
> inserted in target server principal
> --
>
> Key: HADOOP-12617
> URL: https://issues.apache.org/jira/browse/HADOOP-12617
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
>Affects Versions: 2.7.1
> Environment: Java client talking to two secure clusters in different
> Kerberos realms,
> or talking to any secure cluster in non-default realm
>Reporter: Matt Foley
>Assignee: Matt Foley
> Attachments: HADOOP-12617-branch-2.7.001.patch,
> HADOOP-12617-branch-2.7.002.patch, HADOOP-12617.003.patch,
> HADOOP-12617.005.patch, HADOOP-12617.006.patch
>
>
> Note: This is NOT a vulnerability.
> In order for a single Java client to communicate with two different secure
> clusters in different realms (only one of which can be the "default_realm"),
> the client's krb5.conf file must specify both realms, and provide a
> \[domain_realm\] section that maps cluster servers' domains to the correct
> realms. With other appropriate behaviors (such as using the config from each
> cluster to talk to the respective clusters, and a user principal from each
> realm to talk to the respective realms), this is sufficient for most Hadoop
> ecosystem clients.
> But our SPNEGO using clients, such as Oozie, have a bug when it comes to
> talking to a non-default realm. The default realm name gets incorrectly
> inserted into the construction of the target server principal for the
> non-default-realm cluster. Details and proposed solution are given in the
> first comments below.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[ https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15047882#comment-15047882 ] Hudson commented on HADOOP-12617: - FAILURE: Integrated in Hadoop-trunk-Commit #8944 (See [https://builds.apache.org/job/Hadoop-trunk-Commit/8944/]) HADOOP-12617. SPNEGO authentication request to non-default realm gets (mattf: rev ada9c2c410c15e95d0a21ea2941986195606aad8) * hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/KerberosUtil.java * hadoop-common-project/hadoop-common/CHANGES.txt * hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/util/TestKerberosUtil.java > SPNEGO authentication request to non-default realm gets default realm name > inserted in target server principal > -- > > Key: HADOOP-12617 > URL: https://issues.apache.org/jira/browse/HADOOP-12617 > Project: Hadoop Common > Issue Type: Bug > Components: security >Affects Versions: 2.7.1 > Environment: Java client talking to two secure clusters in different > Kerberos realms, > or talking to any secure cluster in non-default realm >Reporter: Matt Foley >Assignee: Matt Foley > Fix For: 2.8.0 > > Attachments: HADOOP-12617-branch-2.7.001.patch, > HADOOP-12617-branch-2.7.003.patch, HADOOP-12617.003.patch, > HADOOP-12617.005.patch, HADOOP-12617.006.patch, HADOOP-12617.007.patch, > HADOOP-12617.008.patch > > > Note: This is NOT a vulnerability. > In order for a single Java client to communicate with two different secure > clusters in different realms (only one of which can be the "default_realm"), > the client's krb5.conf file must specify both realms, and provide a > \[domain_realm\] section that maps cluster servers' domains to the correct > realms. With other appropriate behaviors (such as using the config from each > cluster to talk to the respective clusters, and a user principal from each > realm to talk to the respective realms), this is sufficient for most Hadoop > ecosystem clients. > But our SPNEGO using clients, such as Oozie, have a bug when it comes to > talking to a non-default realm. The default realm name gets incorrectly > inserted into the construction of the target server principal for the > non-default-realm cluster. Details and proposed solution are given in the > first comments below. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[ https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15047768#comment-15047768 ] Matt Foley commented on HADOOP-12617: - Happily, the spurious asflicense check went away. Also, I ran an IBM Java SDK (version 8.0) on a Linux CentOS 6 VM, and established that the correct fully qualified class name for PrincipalName is "com.ibm.security.krb5.PrincipalName", not "com.ibm.security.krb5.internal.PrincipalName". With the corrected path, it works as expected. So I'm uploading one more version of the patchfile, HADOOP-12617.008.patch, with that correction, but there's no need to run the robot again. Committing underway. > SPNEGO authentication request to non-default realm gets default realm name > inserted in target server principal > -- > > Key: HADOOP-12617 > URL: https://issues.apache.org/jira/browse/HADOOP-12617 > Project: Hadoop Common > Issue Type: Bug > Components: security >Affects Versions: 2.7.1 > Environment: Java client talking to two secure clusters in different > Kerberos realms, > or talking to any secure cluster in non-default realm >Reporter: Matt Foley >Assignee: Matt Foley > Attachments: HADOOP-12617-branch-2.7.001.patch, > HADOOP-12617-branch-2.7.002.patch, HADOOP-12617.003.patch, > HADOOP-12617.005.patch, HADOOP-12617.006.patch, HADOOP-12617.007.patch > > > Note: This is NOT a vulnerability. > In order for a single Java client to communicate with two different secure > clusters in different realms (only one of which can be the "default_realm"), > the client's krb5.conf file must specify both realms, and provide a > \[domain_realm\] section that maps cluster servers' domains to the correct > realms. With other appropriate behaviors (such as using the config from each > cluster to talk to the respective clusters, and a user principal from each > realm to talk to the respective realms), this is sufficient for most Hadoop > ecosystem clients. > But our SPNEGO using clients, such as Oozie, have a bug when it comes to > talking to a non-default realm. The default realm name gets incorrectly > inserted into the construction of the target server principal for the > non-default-realm cluster. Details and proposed solution are given in the > first comments below. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[ https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15047854#comment-15047854 ] Matt Foley commented on HADOOP-12617: - Committed to trunk as ada9c2c410c15e95, branch-2 as 472541291bf868c, branch-2.8 as 05a7fb3a9a02326cb46. Should therefore be expected in 2.8.0 and all later releases. > SPNEGO authentication request to non-default realm gets default realm name > inserted in target server principal > -- > > Key: HADOOP-12617 > URL: https://issues.apache.org/jira/browse/HADOOP-12617 > Project: Hadoop Common > Issue Type: Bug > Components: security >Affects Versions: 2.7.1 > Environment: Java client talking to two secure clusters in different > Kerberos realms, > or talking to any secure cluster in non-default realm >Reporter: Matt Foley >Assignee: Matt Foley > Attachments: HADOOP-12617-branch-2.7.001.patch, > HADOOP-12617-branch-2.7.003.patch, HADOOP-12617.003.patch, > HADOOP-12617.005.patch, HADOOP-12617.006.patch, HADOOP-12617.007.patch, > HADOOP-12617.008.patch > > > Note: This is NOT a vulnerability. > In order for a single Java client to communicate with two different secure > clusters in different realms (only one of which can be the "default_realm"), > the client's krb5.conf file must specify both realms, and provide a > \[domain_realm\] section that maps cluster servers' domains to the correct > realms. With other appropriate behaviors (such as using the config from each > cluster to talk to the respective clusters, and a user principal from each > realm to talk to the respective realms), this is sufficient for most Hadoop > ecosystem clients. > But our SPNEGO using clients, such as Oozie, have a bug when it comes to > talking to a non-default realm. The default realm name gets incorrectly > inserted into the construction of the target server principal for the > non-default-realm cluster. Details and proposed solution are given in the > first comments below. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[
https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15047643#comment-15047643
]
Hadoop QA commented on HADOOP-12617:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
35s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 3s
{color} | {color:green} trunk passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 33s
{color} | {color:green} trunk passed with JDK v1.7.0_91 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
8s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 20s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
28s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 11s
{color} | {color:green} trunk passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} trunk passed with JDK v1.7.0_91 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m 44s
{color} | {color:green} the patch passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m 44s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 39s
{color} | {color:green} the patch passed with JDK v1.7.0_91 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
8s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 21s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
34s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 12s
{color} | {color:green} the patch passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed with JDK v1.7.0_91 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 12m 53s
{color} | {color:green} hadoop-auth in the patch passed with JDK v1.8.0_66.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 13m 2s
{color} | {color:green} hadoop-auth in the patch passed with JDK v1.7.0_91.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 71m 33s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:0ca8df7 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12776399/HADOOP-12617.007.patch
|
| JIRA Issue | HADOOP-12617 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux 82bedf2d237d 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh
|
| git revision | trunk / c4084d9 |
| findbugs | v3.0.0 |
| JDK v1.7.0_91 Test Results |
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[ https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15045271#comment-15045271 ] Matt Foley commented on HADOOP-12617: - [~ste...@apache.org], not in a properly configured system. There is some evidence that if run on a system with Kerberos configured on but default realm not defined (either via System Property "java.security.krb5.realm" or krb5.conf parameter "default_realm"), that getDefaultRealm() may throw an exception. But that's a fairly gross misconfiguration. Do you think the error should be suppressed without logging? I had wondered why there was no logging in the KerberosUtils class. Also, does anyone listening have access to the documentation for IBM Java package "com.ibm.security.krb5"? getDomainRealm() follows the model of getDefaultRealm(), but I was unable to confirm that com.ibm.security.krb5.internal.PrincipalName exists and respects the semantics of principal string type "KRB_NT_SRV_HST". Thanks. > SPNEGO authentication request to non-default realm gets default realm name > inserted in target server principal > -- > > Key: HADOOP-12617 > URL: https://issues.apache.org/jira/browse/HADOOP-12617 > Project: Hadoop Common > Issue Type: Bug > Components: security >Affects Versions: 2.7.1 > Environment: Java client talking to two secure clusters in different > Kerberos realms, > or talking to any secure cluster in non-default realm >Reporter: Matt Foley >Assignee: Matt Foley > Attachments: HADOOP-12617-branch-2.7.001.patch, HADOOP-12617.001.patch > > > Note: This is NOT a vulnerability. > In order for a single Java client to communicate with two different secure > clusters in different realms (only one of which can be the "default_realm"), > the client's krb5.conf file must specify both realms, and provide a > \[domain_realm\] section that maps cluster servers' domains to the correct > realms. With other appropriate behaviors (such as using the config from each > cluster to talk to the respective clusters, and a user principal from each > realm to talk to the respective realms), this is sufficient for most Hadoop > ecosystem clients. > But our SPNEGO using clients, such as Oozie, have a bug when it comes to > talking to a non-default realm. The default realm name gets incorrectly > inserted into the construction of the target server principal for the > non-default-realm cluster. Details and proposed solution are given in the > first comments below. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[ https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15044767#comment-15044767 ] Steve Loughran commented on HADOOP-12617: - is there any risk those log@ error messages are going to recur on every IPC call, so overloading logs? > SPNEGO authentication request to non-default realm gets default realm name > inserted in target server principal > -- > > Key: HADOOP-12617 > URL: https://issues.apache.org/jira/browse/HADOOP-12617 > Project: Hadoop Common > Issue Type: Bug > Components: security >Affects Versions: 2.7.1 > Environment: Java client talking to two secure clusters in different > Kerberos realms, > or talking to any secure cluster in non-default realm >Reporter: Matt Foley >Assignee: Matt Foley > Attachments: HADOOP-12617-branch-2.7.001.patch, HADOOP-12617.001.patch > > > Note: This is NOT a vulnerability. > In order for a single Java client to communicate with two different secure > clusters in different realms (only one of which can be the "default_realm"), > the client's krb5.conf file must specify both realms, and provide a > \[domain_realm\] section that maps cluster servers' domains to the correct > realms. With other appropriate behaviors (such as using the config from each > cluster to talk to the respective clusters, and a user principal from each > realm to talk to the respective realms), this is sufficient for most Hadoop > ecosystem clients. > But our SPNEGO using clients, such as Oozie, have a bug when it comes to > talking to a non-default realm. The default realm name gets incorrectly > inserted into the construction of the target server principal for the > non-default-realm cluster. Details and proposed solution are given in the > first comments below. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[
https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15046212#comment-15046212
]
Hadoop QA commented on HADOOP-12617:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
22s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m 29s
{color} | {color:green} trunk passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 25s
{color} | {color:green} trunk passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
8s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 20s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
26s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 12s
{color} | {color:green} trunk passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} trunk passed with JDK v1.7.0_85 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 12s
{color} | {color:red} hadoop-auth in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 17s
{color} | {color:red} root in the patch failed with JDK v1.8.0_66. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 17s {color}
| {color:red} root in the patch failed with JDK v1.8.0_66. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 21s
{color} | {color:red} root in the patch failed with JDK v1.7.0_85. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 21s {color}
| {color:red} root in the patch failed with JDK v1.7.0_85. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 7s
{color} | {color:red} Patch generated 3 new checkstyle issues in
hadoop-common-project/hadoop-auth (total was 15, now 18). {color} |
| {color:red}-1{color} | {color:red} mvnsite {color} | {color:red} 0m 14s
{color} | {color:red} hadoop-auth in the patch failed. {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 12s
{color} | {color:red} hadoop-auth in the patch failed. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 11s
{color} | {color:green} the patch passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed with JDK v1.7.0_85 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 11s {color}
| {color:red} hadoop-auth in the patch failed with JDK v1.8.0_66. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 13s {color}
| {color:red} hadoop-auth in the patch failed with JDK v1.7.0_85. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 18s
{color} | {color:red} Patch generated 3 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 28m 30s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:0ca8df7 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12776228/HADOOP-12617.004.patch
|
| JIRA Issue | HADOOP-12617 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux 6529e0482bdc 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh
|
| git
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[
https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15045724#comment-15045724
]
Hadoop QA commented on HADOOP-12617:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
42s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 15s
{color} | {color:green} trunk passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 41s
{color} | {color:green} trunk passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
8s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 21s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
26s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 13s
{color} | {color:green} trunk passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 13s
{color} | {color:green} trunk passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m 43s
{color} | {color:green} the patch passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m 43s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 38s
{color} | {color:green} the patch passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m 38s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 7s
{color} | {color:red} Patch generated 1 new checkstyle issues in
hadoop-common-project/hadoop-auth (total was 15, now 16). {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 19s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
34s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 12s
{color} | {color:green} the patch passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed with JDK v1.7.0_85 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 3m 40s {color}
| {color:red} hadoop-auth in the patch failed with JDK v1.8.0_66. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 3m 59s {color}
| {color:red} hadoop-auth in the patch failed with JDK v1.7.0_85. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
23s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 53m 50s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_66 Failed junit tests |
hadoop.security.authentication.util.TestKerberosUtil |
| JDK v1.7.0_85 Failed junit tests |
hadoop.security.authentication.util.TestKerberosUtil |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:0ca8df7 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12776163/HADOOP-12617.003.patch
|
| JIRA Issue | HADOOP-12617 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux ba16fe4e49af 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[
https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15045401#comment-15045401
]
Hadoop QA commented on HADOOP-12617:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
59s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 57s
{color} | {color:green} trunk passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 28s
{color} | {color:green} trunk passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
9s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 21s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
28s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 13s
{color} | {color:green} trunk passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} trunk passed with JDK v1.7.0_85 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 15s
{color} | {color:red} hadoop-auth in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 21s
{color} | {color:red} root in the patch failed with JDK v1.8.0_66. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 21s {color}
| {color:red} root in the patch failed with JDK v1.8.0_66. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 24s
{color} | {color:red} root in the patch failed with JDK v1.7.0_85. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 24s {color}
| {color:red} root in the patch failed with JDK v1.7.0_85. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 9s
{color} | {color:red} Patch generated 4 new checkstyle issues in
hadoop-common-project/hadoop-auth (total was 15, now 19). {color} |
| {color:red}-1{color} | {color:red} mvnsite {color} | {color:red} 0m 16s
{color} | {color:red} hadoop-auth in the patch failed. {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 14 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 13s
{color} | {color:red} hadoop-auth in the patch failed. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 13s
{color} | {color:green} the patch passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed with JDK v1.7.0_85 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 13s {color}
| {color:red} hadoop-auth in the patch failed with JDK v1.8.0_66. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 15s {color}
| {color:red} hadoop-auth in the patch failed with JDK v1.7.0_85. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
22s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 32m 9s {color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:0ca8df7 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12776136/HADOOP-12617.002.patch
|
| JIRA Issue | HADOOP-12617 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux 05e7fb9513d8 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[
https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15046318#comment-15046318
]
Hadoop QA commented on HADOOP-12617:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
57s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 6s
{color} | {color:green} trunk passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 27s
{color} | {color:green} trunk passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
9s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 20s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
27s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 13s
{color} | {color:green} trunk passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} trunk passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
19s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 0s
{color} | {color:green} the patch passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 9m 0s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 25s
{color} | {color:green} the patch passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 9m 25s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
8s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 21s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 37s
{color} | {color:red} hadoop-common-project/hadoop-auth introduced 1 new
FindBugs issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 13s
{color} | {color:green} the patch passed with JDK v1.8.0_66 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed with JDK v1.7.0_85 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 41s
{color} | {color:green} hadoop-auth in the patch passed with JDK v1.8.0_66.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m 2s
{color} | {color:green} hadoop-auth in the patch passed with JDK v1.7.0_85.
{color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 19s
{color} | {color:red} Patch generated 3 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 57m 41s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hadoop-common-project/hadoop-auth |
| | Exception is caught when Exception is not thrown in
org.apache.hadoop.security.authentication.util.KerberosUtil.getDomainRealm(String)
At KerberosUtil.java:is not thrown in
org.apache.hadoop.security.authentication.util.KerberosUtil.getDomainRealm(String)
At KerberosUtil.java:[line 129] |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:0ca8df7 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12776242/HADOOP-12617.005.patch
|
| JIRA Issue | HADOOP-12617 |
| Optional Tests | asflicense compile javac javadoc
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[
https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15044218#comment-15044218
]
Hadoop QA commented on HADOOP-12617:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s {color}
| {color:red} HADOOP-12617 does not apply to trunk. Rebase required? Wrong
Branch? See https://wiki.apache.org/hadoop/HowToContribute for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12776012/HADOOP-12617.001.patch
|
| JIRA Issue | HADOOP-12617 |
| Powered by | Apache Yetus 0.1.0-SNAPSHOT http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-HADOOP-Build/8189/console |
This message was automatically generated.
> SPNEGO authentication request to non-default realm gets default realm name
> inserted in target server principal
> --
>
> Key: HADOOP-12617
> URL: https://issues.apache.org/jira/browse/HADOOP-12617
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
>Affects Versions: 2.7.1
> Environment: Java client talking to two secure clusters in different
> Kerberos realms,
> or talking to any secure cluster in non-default realm
>Reporter: Matt Foley
>Assignee: Matt Foley
> Attachments: HADOOP-12617-branch-2.7.001.patch, HADOOP-12617.001.patch
>
>
> Note: This is NOT a vulnerability.
> In order for a single Java client to communicate with two different secure
> clusters in different realms (only one of which can be the "default_realm"),
> the client's krb5.conf file must specify both realms, and provide a
> \[domain_realm\] section that maps cluster servers' domains to the correct
> realms. With other appropriate behaviors (such as using the config from each
> cluster to talk to the respective clusters, and a user principal from each
> realm to talk to the respective realms), this is sufficient for most Hadoop
> ecosystem clients.
> But our SPNEGO using clients, such as Oozie, have a bug when it comes to
> talking to a non-default realm. The default realm name gets incorrectly
> inserted into the construction of the target server principal for the
> non-default-realm cluster. Details and proposed solution are given in the
> first comments below.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[
https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15044177#comment-15044177
]
Matt Foley commented on HADOOP-12617:
-
Teradata engineering team provided debugger information leading to the
following analysis:
A Java client desiring to initiate communication via HTTP/SPNEGO does the
following: In the context of a UGI.doAs(), it calls
org.apache.hadoop.security.authentication.client.KerberosAuthenticator.authenticate(),
which in turn calls doSpnegoSequence().
Inside doSpnegoSequence(), is this code at
https://github.com/apache/hadoop/blob/branch-2.7.2/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/client/KerberosAuthenticator.java#L287-L298
:
{code}
Subject.doAs(subject, new PrivilegedExceptionAction() {
public Void run() throws Exception {
GSSContext gssContext = null;
try {
GSSManager gssManager = GSSManager.getInstance();
String servicePrincipal = KerberosUtil.getServicePrincipal("HTTP",
KerberosAuthenticator.this.url.getHost());
Oid oid = KerberosUtil.getOidInstance("NT_GSS_KRB5_PRINCIPAL");
GSSName serviceName = gssManager.createName(servicePrincipal, oid);
{code}
Subject is set with the correct user principal and target server name and
realm. After executing the line:
{code}
String servicePrincipal = KerberosUtil.getServicePrincipal("HTTP",
KerberosAuthenticator.this.url.getHost());
{code}
The ServicePrincipal is returned as: "HTTP/hostname" (with an actual value for
"hostname"), but no realm.
Then, when it gets the serviceName
{code}
GSSName serviceName = gssManager.createName(servicePrincipal, oid);
{code}
The resulting data structure includes a subfield Krb5PrincipalName with value
"HTTP/hostname@DEFAULTREALM", where "hostname" and "DEFAULTREALM" are of course
substituted with real values. The default realm should not be here. It is
required that the correct non-default realm should be derived from the domain
of "hostname".
However, the second component of a principal is, strictly speaking, the
"instance", not the "server". Thus, the Kerb libraries are not inferring the
realm from the domain portion of the server name, because the formal semantics
don't actually match; and of course there is nowhere else the realm could be
correctly inferred from. KerberosUtil.getServicePrincipal() has to return a
full principal with correct realm, rather than the short principal with
inferred default realm.
> SPNEGO authentication request to non-default realm gets default realm name
> inserted in target server principal
> --
>
> Key: HADOOP-12617
> URL: https://issues.apache.org/jira/browse/HADOOP-12617
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
>Affects Versions: 2.7.1
> Environment: Java client talking to two secure clusters in different
> Kerberos realms,
> or talking to any secure cluster in non-default realm
>Reporter: Matt Foley
>Assignee: Matt Foley
>
> Note: This is NOT a vulnerability.
> In order for a single Java client to communicate with two different secure
> clusters in different realms (only one of which can be the "default_realm"),
> the client's krb5.conf file must specify both realms, and provide a
> \[domain_realm\] section that maps cluster servers' domains to the correct
> realms. With other appropriate behaviors (such as using the config from each
> cluster to talk to the respective clusters, and a user principal from each
> realm to talk to the respective realms), this is sufficient for most Hadoop
> ecosystem clients.
> But our SPNEGO using clients, such as Oozie, have a bug when it comes to
> talking to a non-default realm. The default realm name gets incorrectly
> inserted into the construction of the target server principal for the
> non-default-realm cluster. Details and proposed solution are given in the
> first comments below.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
[ https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15044180#comment-15044180 ] Matt Foley commented on HADOOP-12617: - The proposed patch provides the required functionality with no changes to API signatures or exceptions, and following the model of other code in KerberosUtils.java. Furthermore, I grepped all java files in a broad set of Hadoop ecosystem components: * accumulo, atlas, calcite, datafu, falcon, flume, hadoop, hbase, hive, hue, kafka, knox, mahout, oozie, phoenix, pig, ranger, slider, spark, sqoop, storm, tez, zookeeper and found that no code calls KerberosUtils.getServicePrincipal() directly except that in the Hadoop auth package. Both instances there use the result ONLY as an argument for an immediate call to gssManager.createName(), which accepts the fully qualified principal and does the right thing with it. So I believe this patch is safe. > SPNEGO authentication request to non-default realm gets default realm name > inserted in target server principal > -- > > Key: HADOOP-12617 > URL: https://issues.apache.org/jira/browse/HADOOP-12617 > Project: Hadoop Common > Issue Type: Bug > Components: security >Affects Versions: 2.7.1 > Environment: Java client talking to two secure clusters in different > Kerberos realms, > or talking to any secure cluster in non-default realm >Reporter: Matt Foley >Assignee: Matt Foley > > Note: This is NOT a vulnerability. > In order for a single Java client to communicate with two different secure > clusters in different realms (only one of which can be the "default_realm"), > the client's krb5.conf file must specify both realms, and provide a > \[domain_realm\] section that maps cluster servers' domains to the correct > realms. With other appropriate behaviors (such as using the config from each > cluster to talk to the respective clusters, and a user principal from each > realm to talk to the respective realms), this is sufficient for most Hadoop > ecosystem clients. > But our SPNEGO using clients, such as Oozie, have a bug when it comes to > talking to a non-default realm. The default realm name gets incorrectly > inserted into the construction of the target server principal for the > non-default-realm cluster. Details and proposed solution are given in the > first comments below. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
