[ 
https://issues.apache.org/jira/browse/HADOOP-10398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942127#comment-13942127
 ] 

Bowen Zhang commented on HADOOP-10398:
--------------------------------------

[~rkanter], 1) in production, what you said is theoretically true. But, we do 
see customers share or mount the same directories on flubber. This is also 
probably why we have this "-Doozie.auth.token.cache" flag to begin with.
2) No, I don't have this problem when we don't set "-Doozie.auth.token.cache" 
to false.
The core of the issue is this: when enabling security, to kill a job, there are 
two ways to set "user.name" which AuthorizationService.java will use to 
authorize operation in "public void authorizeForJob(String user, String jobId, 
boolean write) throws AuthorizationException". One is to read the token cahe 
file, the other is through calling 
"if (!currentToken.isSet()) {
            Authenticator authenticator = getAuthenticator();
            try {
                new AuthenticatedURL(authenticator).openConnection(url, 
currentToken);
            }
            catch (AuthenticationException ex) {
                AUTH_TOKEN_CACHE_FILE.delete();
                throw new 
OozieClientException(OozieClientException.AUTHENTICATION,
                                               "Could not authenticate, " + 
ex.getMessage(), ex);
            }
        }"
in authoozieclient.java. Due to hadoop-10078, we no longer get "user.name" 
anymore


> KerberosAuthenticator failed to fall back to PseudoAuthenticator after 
> HADOOP-10078
> -----------------------------------------------------------------------------------
>
>                 Key: HADOOP-10398
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10398
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>            Reporter: Tsz Wo Nicholas Sze
>            Assignee: Tsz Wo Nicholas Sze
>         Attachments: a.txt, c10398_20140310.patch
>
>
> {code}
> //KerberosAuthenticator.java
>       if (conn.getResponseCode() == HttpURLConnection.HTTP_OK) {
>         LOG.debug("JDK performed authentication on our behalf.");
>         // If the JDK already did the SPNEGO back-and-forth for
>         // us, just pull out the token.
>         AuthenticatedURL.extractToken(conn, token);
>         return;
>       } else ...
> {code}
> The problem of the code above is that HTTP_OK does not implies authentication 
> completed.  We should check if the token can be extracted successfully.
> This problem was reported by [~bowenzhangusa] in [this 
> comment|https://issues.apache.org/jira/browse/HADOOP-10078?focusedCommentId=13896823&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896823]
>  earlier.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to