[
https://issues.apache.org/jira/browse/HADOOP-11404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Chu updated HADOOP-11404:
---------------------------------
Description:
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.
was:
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.
> 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
>
> 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)
