[jira] [Commented] (HADOOP-11404) Clarify the "expected client Kerberos principal is null" authorization message
[
https://issues.apache.org/jira/browse/HADOOP-11404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15189183#comment-15189183
]
Hudson commented on HADOOP-11404:
-
FAILURE: Integrated in Hadoop-trunk-Commit #9447 (See
[https://builds.apache.org/job/Hadoop-trunk-Commit/9447/])
HADOOP-11404. Clarify the "expected client Kerberos principal is null" (harsh:
rev 318c9b68b059981796f2742b4b7ee604ccdc47e5)
*
hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/authorize/ServiceAuthorizationManager.java
> Clarify the "expected client Kerberos principal is null" authorization message
> --
>
> Key: HADOOP-11404
> URL: https://issues.apache.org/jira/browse/HADOOP-11404
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
>Affects Versions: 2.2.0
>Reporter: Stephen Chu
>Assignee: Stephen Chu
>Priority: Minor
> Labels: BB2015-05-TBR, supportability
> Attachments: HADOOP-11404.001.patch, HADOOP-11404.002.patch,
> HADOOP-11404.003.patch
>
>
> In {{ServiceAuthorizationManager#authorize}}, we throw an
> {{AuthorizationException}} with message "expected client Kerberos principal
> is null" when authorization fails.
> However, this is a confusing log message, because it leads users to believe
> there was a Kerberos authentication problem, when in fact the the user could
> have authenticated successfully.
> {code}
> if((clientPrincipal != null && !clientPrincipal.equals(user.getUserName()))
> ||
>acls.length != 2 || !acls[0].isUserAllowed(user) ||
> acls[1].isUserAllowed(user)) {
> AUDITLOG.warn(AUTHZ_FAILED_FOR + user + " for protocol=" + protocol
> + ", expected client Kerberos principal is " + clientPrincipal);
> throw new AuthorizationException("User " + user +
> " is not authorized for protocol " + protocol +
> ", expected client Kerberos principal is " + clientPrincipal);
> }
> AUDITLOG.info(AUTHZ_SUCCESSFUL_FOR + user + " for protocol="+protocol);
> {code}
> In the above code, if clientPrincipal is null, then the user is authenticated
> successfully but denied by a configured ACL, not a Kerberos issue. We should
> improve this log message to state this.
> Thanks to [~tlipcon] for finding this and proposing a fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11404) Clarify the "expected client Kerberos principal is null" authorization message
[
https://issues.apache.org/jira/browse/HADOOP-11404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15189177#comment-15189177
]
Harsh J commented on HADOOP-11404:
--
Thanks [~ste...@apache.org]! Committing shortly.
> Clarify the "expected client Kerberos principal is null" authorization message
> --
>
> Key: HADOOP-11404
> URL: https://issues.apache.org/jira/browse/HADOOP-11404
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
>Affects Versions: 2.2.0
>Reporter: Stephen Chu
>Assignee: Stephen Chu
>Priority: Minor
> Labels: BB2015-05-TBR, supportability
> Attachments: HADOOP-11404.001.patch, HADOOP-11404.002.patch,
> HADOOP-11404.003.patch
>
>
> In {{ServiceAuthorizationManager#authorize}}, we throw an
> {{AuthorizationException}} with message "expected client Kerberos principal
> is null" when authorization fails.
> However, this is a confusing log message, because it leads users to believe
> there was a Kerberos authentication problem, when in fact the the user could
> have authenticated successfully.
> {code}
> if((clientPrincipal != null && !clientPrincipal.equals(user.getUserName()))
> ||
>acls.length != 2 || !acls[0].isUserAllowed(user) ||
> acls[1].isUserAllowed(user)) {
> AUDITLOG.warn(AUTHZ_FAILED_FOR + user + " for protocol=" + protocol
> + ", expected client Kerberos principal is " + clientPrincipal);
> throw new AuthorizationException("User " + user +
> " is not authorized for protocol " + protocol +
> ", expected client Kerberos principal is " + clientPrincipal);
> }
> AUDITLOG.info(AUTHZ_SUCCESSFUL_FOR + user + " for protocol="+protocol);
> {code}
> In the above code, if clientPrincipal is null, then the user is authenticated
> successfully but denied by a configured ACL, not a Kerberos issue. We should
> improve this log message to state this.
> Thanks to [~tlipcon] for finding this and proposing a fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11404) Clarify the "expected client Kerberos principal is null" authorization message
[
https://issues.apache.org/jira/browse/HADOOP-11404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15188971#comment-15188971
]
Steve Loughran commented on HADOOP-11404:
-
+1 once checkstyle is happy
> Clarify the "expected client Kerberos principal is null" authorization message
> --
>
> Key: HADOOP-11404
> URL: https://issues.apache.org/jira/browse/HADOOP-11404
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
>Affects Versions: 2.2.0
>Reporter: Stephen Chu
>Assignee: Stephen Chu
>Priority: Minor
> Labels: BB2015-05-TBR, supportability
> Attachments: HADOOP-11404.001.patch, HADOOP-11404.002.patch,
> HADOOP-11404.003.patch
>
>
> In {{ServiceAuthorizationManager#authorize}}, we throw an
> {{AuthorizationException}} with message "expected client Kerberos principal
> is null" when authorization fails.
> However, this is a confusing log message, because it leads users to believe
> there was a Kerberos authentication problem, when in fact the the user could
> have authenticated successfully.
> {code}
> if((clientPrincipal != null && !clientPrincipal.equals(user.getUserName()))
> ||
>acls.length != 2 || !acls[0].isUserAllowed(user) ||
> acls[1].isUserAllowed(user)) {
> AUDITLOG.warn(AUTHZ_FAILED_FOR + user + " for protocol=" + protocol
> + ", expected client Kerberos principal is " + clientPrincipal);
> throw new AuthorizationException("User " + user +
> " is not authorized for protocol " + protocol +
> ", expected client Kerberos principal is " + clientPrincipal);
> }
> AUDITLOG.info(AUTHZ_SUCCESSFUL_FOR + user + " for protocol="+protocol);
> {code}
> In the above code, if clientPrincipal is null, then the user is authenticated
> successfully but denied by a configured ACL, not a Kerberos issue. We should
> improve this log message to state this.
> Thanks to [~tlipcon] for finding this and proposing a fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11404) Clarify the "expected client Kerberos principal is null" authorization message
[
https://issues.apache.org/jira/browse/HADOOP-11404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15188969#comment-15188969
]
Hadoop QA commented on HADOOP-11404:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s
{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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {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} 9m 18s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 7s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m 5s
{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} 1m
44s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 5s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 13s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 8s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 9m 8s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 6s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m 6s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m 3s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {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} 2m 3s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 8s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 8s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 10m 31s
{color} | {color:green} hadoop-common in the patch passed with JDK v1.8.0_74.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 9m 32s {color}
| {color:red} hadoop-common in the patch failed with JDK v1.7.0_95. {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} 76m 35s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.7.0_95 Failed junit tests |
hadoop.security.ssl.TestReloadingX509TrustManager |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:0ca8df7 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12792469/HADOOP-11404.003.patch
|
| JIRA Issue | HADOOP-11404 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux fdd327eb4885 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64
[jira] [Commented] (HADOOP-11404) Clarify the "expected client Kerberos principal is null" authorization message
[
https://issues.apache.org/jira/browse/HADOOP-11404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15188845#comment-15188845
]
Hadoop QA commented on HADOOP-11404:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 14s
{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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
10s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 18s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m 26s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
20s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 59s
{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} 1m
37s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 2s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 7s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 14s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m 14s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m 20s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m 20s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 20s
{color} | {color:red} hadoop-common-project/hadoop-common: patch generated 2
new + 29 unchanged - 0 fixed = 31 total (was 29) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 57s
{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} 1m
51s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 1s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 5s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 20m 26s {color}
| {color:red} hadoop-common in the patch failed with JDK v1.8.0_74. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 10m 0s
{color} | {color:green} hadoop-common in the patch passed with JDK v1.7.0_95.
{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} 82m 5s {color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_74 Timed out junit tests |
org.apache.hadoop.http.TestHttpServerLifecycle |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:0ca8df7 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12792439/HADOOP-11404.002.patch
|
| JIRA Issue | HADOOP-11404 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux f8de1a791f7b
[jira] [Commented] (HADOOP-11404) Clarify the "expected client Kerberos principal is null" authorization message
[
https://issues.apache.org/jira/browse/HADOOP-11404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15188715#comment-15188715
]
Harsh J commented on HADOOP-11404:
--
+1, patch still applies. Will commit in a day unless you have any objection,
[~ste...@apache.org].
> Clarify the "expected client Kerberos principal is null" authorization message
> --
>
> Key: HADOOP-11404
> URL: https://issues.apache.org/jira/browse/HADOOP-11404
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
>Affects Versions: 2.2.0
>Reporter: Stephen Chu
>Assignee: Stephen Chu
>Priority: Minor
> Labels: BB2015-05-TBR, supportability
> Attachments: HADOOP-11404.001.patch
>
>
> In {{ServiceAuthorizationManager#authorize}}, we throw an
> {{AuthorizationException}} with message "expected client Kerberos principal
> is null" when authorization fails.
> However, this is a confusing log message, because it leads users to believe
> there was a Kerberos authentication problem, when in fact the the user could
> have authenticated successfully.
> {code}
> if((clientPrincipal != null && !clientPrincipal.equals(user.getUserName()))
> ||
>acls.length != 2 || !acls[0].isUserAllowed(user) ||
> acls[1].isUserAllowed(user)) {
> AUDITLOG.warn(AUTHZ_FAILED_FOR + user + " for protocol=" + protocol
> + ", expected client Kerberos principal is " + clientPrincipal);
> throw new AuthorizationException("User " + user +
> " is not authorized for protocol " + protocol +
> ", expected client Kerberos principal is " + clientPrincipal);
> }
> AUDITLOG.info(AUTHZ_SUCCESSFUL_FOR + user + " for protocol="+protocol);
> {code}
> In the above code, if clientPrincipal is null, then the user is authenticated
> successfully but denied by a configured ACL, not a Kerberos issue. We should
> improve this log message to state this.
> Thanks to [~tlipcon] for finding this and proposing a fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11404) Clarify the "expected client Kerberos principal is null" authorization message
[
https://issues.apache.org/jira/browse/HADOOP-11404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14741356#comment-14741356
]
Hadoop QA commented on HADOOP-11404:
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | pre-patch | 17m 19s | Pre-patch trunk compilation is
healthy. |
| {color:green}+1{color} | @author | 0m 0s | The patch does not contain any
@author tags. |
| {color:red}-1{color} | tests included | 0m 0s | The patch doesn't appear
to include any new or modified tests. Please justify why no new tests are
needed for this patch. Also please list what manual steps were performed to
verify this patch. |
| {color:green}+1{color} | javac | 7m 57s | There were no new javac warning
messages. |
| {color:green}+1{color} | javadoc | 10m 9s | There were no new javadoc
warning messages. |
| {color:green}+1{color} | release audit | 0m 24s | The applied patch does
not increase the total number of release audit warnings. |
| {color:red}-1{color} | checkstyle | 1m 5s | The applied patch generated 3
new checkstyle issues (total was 29, now 32). |
| {color:red}-1{color} | whitespace | 0m 0s | The patch has 1 line(s) that
end in whitespace. Use git apply --whitespace=fix. |
| {color:green}+1{color} | install | 1m 29s | mvn install still works. |
| {color:green}+1{color} | eclipse:eclipse | 0m 34s | The patch built with
eclipse:eclipse. |
| {color:green}+1{color} | findbugs | 1m 52s | The patch does not introduce
any new Findbugs (version 3.0.0) warnings. |
| {color:red}-1{color} | common tests | 22m 11s | Tests failed in
hadoop-common. |
| | | 63m 5s | |
\\
\\
|| Reason || Tests ||
| Failed unit tests | hadoop.ipc.TestSaslRPC |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12687105/HADOOP-11404.001.patch
|
| Optional Tests | javadoc javac unit findbugs checkstyle |
| git revision | trunk / 15a557f |
| checkstyle |
https://builds.apache.org/job/PreCommit-HADOOP-Build/7642/artifact/patchprocess/diffcheckstylehadoop-common.txt
|
| whitespace |
https://builds.apache.org/job/PreCommit-HADOOP-Build/7642/artifact/patchprocess/whitespace.txt
|
| hadoop-common test log |
https://builds.apache.org/job/PreCommit-HADOOP-Build/7642/artifact/patchprocess/testrun_hadoop-common.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HADOOP-Build/7642/testReport/ |
| Java | 1.7.0_55 |
| uname | Linux asf900.gq1.ygridcore.net 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 |
| Console output |
https://builds.apache.org/job/PreCommit-HADOOP-Build/7642/console |
This message was automatically generated.
> Clarify the "expected client Kerberos principal is null" authorization message
> --
>
> Key: HADOOP-11404
> URL: https://issues.apache.org/jira/browse/HADOOP-11404
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
>Affects Versions: 2.2.0
>Reporter: Stephen Chu
>Assignee: Stephen Chu
>Priority: Minor
> Labels: BB2015-05-TBR, supportability
> Attachments: HADOOP-11404.001.patch
>
>
> In {{ServiceAuthorizationManager#authorize}}, we throw an
> {{AuthorizationException}} with message "expected client Kerberos principal
> is null" when authorization fails.
> However, this is a confusing log message, because it leads users to believe
> there was a Kerberos authentication problem, when in fact the the user could
> have authenticated successfully.
> {code}
> if((clientPrincipal != null && !clientPrincipal.equals(user.getUserName()))
> ||
>acls.length != 2 || !acls[0].isUserAllowed(user) ||
> acls[1].isUserAllowed(user)) {
> AUDITLOG.warn(AUTHZ_FAILED_FOR + user + " for protocol=" + protocol
> + ", expected client Kerberos principal is " + clientPrincipal);
> throw new AuthorizationException("User " + user +
> " is not authorized for protocol " + protocol +
> ", expected client Kerberos principal is " + clientPrincipal);
> }
> AUDITLOG.info(AUTHZ_SUCCESSFUL_FOR + user + " for protocol="+protocol);
> {code}
> In the above code, if clientPrincipal is null, then the user is authenticated
> successfully but denied by a configured ACL, not a Kerberos issue. We should
> improve this log message to state this.
> Thanks to [~tlipcon] for finding this and proposing a fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11404) Clarify the expected client Kerberos principal is null authorization message
[
https://issues.apache.org/jira/browse/HADOOP-11404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14525671#comment-14525671
]
Hadoop QA commented on HADOOP-11404:
(!) The patch artifact directory has been removed!
This is a fatal error for test-patch.sh. Aborting.
Jenkins (node H4) information at
https://builds.apache.org/job/PreCommit-HADOOP-Build/6453/ may provide some
hints.
Clarify the expected client Kerberos principal is null authorization message
--
Key: HADOOP-11404
URL: https://issues.apache.org/jira/browse/HADOOP-11404
Project: Hadoop Common
Issue Type: Improvement
Components: security
Affects Versions: 2.2.0
Reporter: Stephen Chu
Assignee: Stephen Chu
Priority: Minor
Labels: supportability
Attachments: HADOOP-11404.001.patch
In {{ServiceAuthorizationManager#authorize}}, we throw an
{{AuthorizationException}} with message expected client Kerberos principal
is null when authorization fails.
However, this is a confusing log message, because it leads users to believe
there was a Kerberos authentication problem, when in fact the the user could
have authenticated successfully.
{code}
if((clientPrincipal != null !clientPrincipal.equals(user.getUserName()))
||
acls.length != 2 || !acls[0].isUserAllowed(user) ||
acls[1].isUserAllowed(user)) {
AUDITLOG.warn(AUTHZ_FAILED_FOR + user + for protocol= + protocol
+ , expected client Kerberos principal is + clientPrincipal);
throw new AuthorizationException(User + user +
is not authorized for protocol + protocol +
, expected client Kerberos principal is + clientPrincipal);
}
AUDITLOG.info(AUTHZ_SUCCESSFUL_FOR + user + for protocol=+protocol);
{code}
In the above code, if clientPrincipal is null, then the user is authenticated
successfully but denied by a configured ACL, not a Kerberos issue. We should
improve this log message to state this.
Thanks to [~tlipcon] for finding this and proposing a fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11404) Clarify the expected client Kerberos principal is null authorization message
[
https://issues.apache.org/jira/browse/HADOOP-11404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245872#comment-14245872
]
Hadoop QA commented on HADOOP-11404:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12687105/HADOOP-11404.001.patch
against trunk revision 25a0440.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:red}-1 findbugs{color}. The patch appears to introduce 3 new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
hadoop-common-project/hadoop-common:
org.apache.hadoop.crypto.random.TestOsSecureRandom
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/5263//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HADOOP-Build/5263//artifact/patchprocess/newPatchFindbugsWarningshadoop-common.html
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/5263//console
This message is automatically generated.
Clarify the expected client Kerberos principal is null authorization message
--
Key: HADOOP-11404
URL: https://issues.apache.org/jira/browse/HADOOP-11404
Project: Hadoop Common
Issue Type: Improvement
Components: security
Affects Versions: 2.2.0
Reporter: Stephen Chu
Assignee: Stephen Chu
Priority: Minor
Labels: supportability
Attachments: HADOOP-11404.001.patch
In {{ServiceAuthorizationManager#authorize}}, we throw an
{{AuthorizationException}} with message expected client Kerberos principal
is null when authorization fails.
However, this is a confusing log message, because it leads users to believe
there was a Kerberos authentication problem, when in fact the the user could
have authenticated successfully.
{code}
if((clientPrincipal != null !clientPrincipal.equals(user.getUserName()))
||
acls.length != 2 || !acls[0].isUserAllowed(user) ||
acls[1].isUserAllowed(user)) {
AUDITLOG.warn(AUTHZ_FAILED_FOR + user + for protocol= + protocol
+ , expected client Kerberos principal is + clientPrincipal);
throw new AuthorizationException(User + user +
is not authorized for protocol + protocol +
, expected client Kerberos principal is + clientPrincipal);
}
AUDITLOG.info(AUTHZ_SUCCESSFUL_FOR + user + for protocol=+protocol);
{code}
In the above code, if clientPrincipal is null, then the user is authenticated
successfully but denied by a configured ACL, not a Kerberos issue. We should
improve this log message to state this.
Thanks to [~tlipcon] for finding this and proposing a fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11404) Clarify the expected client Kerberos principal is null authorization message
[
https://issues.apache.org/jira/browse/HADOOP-11404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245998#comment-14245998
]
Stephen Chu commented on HADOOP-11404:
--
The findbugs warnings and TestOsSecureRandom are unrelated. No new test because
this patch changes only a log message.
Clarify the expected client Kerberos principal is null authorization message
--
Key: HADOOP-11404
URL: https://issues.apache.org/jira/browse/HADOOP-11404
Project: Hadoop Common
Issue Type: Improvement
Components: security
Affects Versions: 2.2.0
Reporter: Stephen Chu
Assignee: Stephen Chu
Priority: Minor
Labels: supportability
Attachments: HADOOP-11404.001.patch
In {{ServiceAuthorizationManager#authorize}}, we throw an
{{AuthorizationException}} with message expected client Kerberos principal
is null when authorization fails.
However, this is a confusing log message, because it leads users to believe
there was a Kerberos authentication problem, when in fact the the user could
have authenticated successfully.
{code}
if((clientPrincipal != null !clientPrincipal.equals(user.getUserName()))
||
acls.length != 2 || !acls[0].isUserAllowed(user) ||
acls[1].isUserAllowed(user)) {
AUDITLOG.warn(AUTHZ_FAILED_FOR + user + for protocol= + protocol
+ , expected client Kerberos principal is + clientPrincipal);
throw new AuthorizationException(User + user +
is not authorized for protocol + protocol +
, expected client Kerberos principal is + clientPrincipal);
}
AUDITLOG.info(AUTHZ_SUCCESSFUL_FOR + user + for protocol=+protocol);
{code}
In the above code, if clientPrincipal is null, then the user is authenticated
successfully but denied by a configured ACL, not a Kerberos issue. We should
improve this log message to state this.
Thanks to [~tlipcon] for finding this and proposing a fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
