Bug 617267 - occasional unexplained authentication failure using cyrus-sasl and GSSAPI
occasional unexplained authentication failure using cyrus-sasl and GSSAPI
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cyrus-sasl (Show other bugs)
5.4
All Linux
low Severity high
: rc
: ---
Assigned To: Petr Lautrbach
BaseOS QE Security Team
:
: 598948 (view as bug list)
Depends On:
Blocks: 613011
  Show dependency treegraph
 
Reported: 2010-07-22 11:59 EDT by Gordon Sim
Modified: 2013-03-13 11:00 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-13 11:00:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gordon Sim 2010-07-22 11:59:26 EDT
Description of problem:

Using the sasl2-sample-client and sasl2-sample-server with GSSAPI results in very occasional authentication failures for no apparent reason. Running the client in a loop will fail after some time, but after failure an immediate retry succeeds (and so the ticket is clearly still valid).

Version-Release number of selected component (if applicable):

cyrus-sasl-gssapi-2.1.22-5.el5
krb5-libs-1.6.1-36.el5
krb5-server-1.6.1-36.el5

How reproducible:

Occasionally

Steps to Reproduce:
1. start sasl2-sample-server with GSSAPI
2. run sasl2-sampl-client with GSSAPI in a loop (pipe in appropriate auth id)
  
Actual results:

Get occasional unexplained authentication failures (after which successful authentication is immediately observed without any further kinit).

Expected results:

Should not fail authentication unless ticket expires.

Additional info:

The issue was originally noticed with qpid (M component of MRG), where occasionally GSSAPI authentication failed without any reason (it passed successfully immediately before and after the failure case, so ticket was valid) - see bug 598948. This was worked around by not explicitly supplying the authorisation id and allowing that to be inferred.
Comment 1 Gordon Sim 2010-08-02 08:04:11 EDT
Any thoughts or progress on this yet?
Comment 2 Petr Lautrbach 2012-03-08 05:16:39 EST
I'm not able to reproduce this issue. My script's running almost 12 hour in loop without any failure. Are you able to reproduce it? Can you provide sasl2-sample-server and klist output when authentication failures? Is it possible that something refreshes ticket after fail?
Comment 3 Gordon Sim 2012-03-13 06:21:54 EDT
I certainly was able to reproduce it quite easily (though it could take some time for the error to appear). At present I don't have an equivalent test environment set up so it will take some time to have another try. I don't believe anything could have refreshed the ticket (I did look at klist output at the time and saw nothing unexpected there).
Comment 4 Justin Ross 2012-12-11 15:41:18 EST
*** Bug 598948 has been marked as a duplicate of this bug. ***
Comment 5 Petr Lautrbach 2013-03-13 11:00:53 EDT
I am sorry, but it is now too late in the RHEL-5 release cycle.
RHEL-5.10 (the next RHEL-5 minor release) is going to be the first
production phase 2 [1] release of RHEL-5. Since phase 2 we'll be
addressing only security and critical issues.

[1] https://access.redhat.com/support/policy/updates/errata/

Note You need to log in before you can comment on or make changes to this bug.