Bug 684892

Summary: GSS authentication is broken in libcurl, preventing 'git clone' from working
Product: Red Hat Enterprise Linux 6 Reporter: Marcus Sundberg <devel>
Component: curlAssignee: Kamil Dudka <kdudka>
Status: CLOSED ERRATA QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: ebenes, mhusnain, mvadkert, ovasik, prc
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Kerberos authentication was broken for reused curl handles, which prevented "git clone"' from working with Kerberos authenticated web servers. This is now fixed to allow "git clone" operations to successfully authenticate and carry out operations.
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 13:12:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Patch fixing the problem
none
Log showing the problem, from GIT_CURL_VERBOSE=1 git clone none

Description Marcus Sundberg 2011-03-14 18:03:01 UTC
Created attachment 484268 [details]
Patch fixing the problem

Description of problem:
git clone against a repository using GSS auth does not work with recent
libcurl versions. It used to work fine with libcurl 7.15.5 included
in RHEL 5, but in recent curl versions including the 7.19.7-16 version
included in RHEL 6 it's broken.

Version-Release number of selected component (if applicable):
libcurl-7.19.7-16.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Try to do a 'git clone' against a repository using GSS authentication
  
Actual results:
First request (GET) authenticates successfully.
Second request (POST to git-upload-pack) fails without authentication being
tried and nothing is cloned.

Expected results:
Complete 'git clone' is successfully authenticated.

Additional info:
The problem is this code in Curl_http_input_auth():

    if(data->state.negotiate.state == GSS_AUTHSENT) {
      /* if we sent GSS authentication in the outgoing request and we get this
         back, we're in trouble */
      infof(data, "Authentication problem. Ignoring this.\n");
      data->state.authproblem = TRUE;
    }

When a struct connectdata is used for multiple requests and the
first request was authenticated with GSS, data->state.negotiate.state
is not reset for subsequent calls to Curl_http_input_auth,
which causes the above if statement to be true and the next request
to fail without authentication being tried.

The attached patch makes sure that the state is always set to
GSS_AUTHNONE in output_auth_headers() unless it actually did
a successful Curl_output_negotiate().

The attached patch has already been accepted in upstream curl:
https://github.com/bagder/curl/commit/6f0ee717c3752e06144e87b45bb56c24ce8237f7

Comment 1 Marcus Sundberg 2011-03-14 18:06:21 UTC
Created attachment 484270 [details]
Log showing the problem, from GIT_CURL_VERBOSE=1 git clone

When using libcurl 7.15.5 from RHEL 5, or using my patch, the
"* Authentication problem. Ignoring this."
line interleaved in the last 401 does not appear, and libcurl
successfully resends the request with proper authentication.

Comment 12 Misha H. Ali 2011-04-20 05:27:56 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Kerberos authentication was broken for reused curl handles, which prevented "git clone"' from working with Kerberos authenticated web servers. This is now fixed to allow "git clone" operations to successfully authenticate and carry out operations.

Comment 13 errata-xmlrpc 2011-05-19 13:12:42 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0573.html