hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-3676) handleSaslConnection failure doesn't try to renew the correct UGI
Date Thu, 19 Jul 2012 17:28:35 GMT

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

Daryn Sharp commented on HDFS-3676:
-----------------------------------

bq. Only the login-user is expected to have kerberos tgt and the renewal is attempted for
such users
That's not entirely true.  I think you might be missing the key point that the UGI api allows
for multiple TGT authenticated UGIs.

bq.  Is there a good use case where we would like to renew the kerberos credentials of arbitrary
users? 
Yes, it's breaking fuse.  But the bigger question is why break a usable api? A non-login UGI
with a TGT can be used to open a connection and the UGI api exists to log it back in.  Why
should the rpc client artificially prevent this UGI from being logged back in?

bq. note for proxy-user cases, getLoginUser will return the right user
No, not always.  The SASL code above _assumes_ the default login user is the real user of
a proxy UGI.  If you create another TGT authenticated UGI and use it to create a proxy UGI,
then the real user does not match the login user.

                
> handleSaslConnection failure doesn't try to renew the correct UGI
> -----------------------------------------------------------------
>
>                 Key: HDFS-3676
>                 URL: https://issues.apache.org/jira/browse/HDFS-3676
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 2.1.0-alpha
>            Reporter: Colin Patrick McCabe
>            Assignee: Colin Patrick McCabe
>
> Client.java has this code:
> {code}
>     private synchronized void handleSaslConnectionFailure(
>         final int currRetries, final int maxRetries, final Exception ex,
>         final Random rand, final UserGroupInformation ugi) throws IOException,
>         InterruptedException {
>       ugi.doAs(new PrivilegedExceptionAction<Object>() {
>         public Object run() throws IOException, InterruptedException {
>           final short MAX_BACKOFF = 5000;
>           closeConnection();
>           disposeSasl();
>           if (shouldAuthenticateOverKrb()) {
>             if (currRetries < maxRetries) {
>               if(LOG.isDebugEnabled()) {
>                 LOG.debug("Exception encountered while connecting to "
>                     + "the server : " + ex);
>               }
>               // try re-login
>               if (UserGroupInformation.isLoginKeytabBased()) {
>                 UserGroupInformation.getLoginUser().reloginFromKeytab();
>               } else {
>                 UserGroupInformation.getLoginUser().reloginFromTicketCache();
>               }
> {code}
> It's not renewing the UGI that had the problem, it's renewing the loginUser.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message