Bug 165432 - 'Request is a replay' error at SVN operations
'Request is a replay' error at SVN operations
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: mod_auth_kerb (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-09 05:55 EDT by Enrico Scholz
Modified: 2008-02-28 05:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-28 05:00:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Quick'n dirty hack with sleep and retry-as-long-we-get-errors loop (871 bytes, patch)
2005-08-10 08:14 EDT, Enrico Scholz
no flags Details | Diff

  None (edit)
Description Enrico Scholz 2005-08-09 05:55:54 EDT
Description of problem:

When doing basic-auth style authentication (using login + password
instead of krb5 ticket) with mod_auth_kerb'erized SVN server, the
svn operations will fail randomly because the krb5 server detects
replay-attacks.

E.g. apache log shows

| [Tue Aug 09 11:23:15 2005] [error] [client 192.168.3.251] failed to verify krb5 credentials: Request is a replay

and the kdc log

| Aug  9 11:23:15 kerberos@rochester krb5kdc[17936]: TGS_REQ (3 etypes {16 1 3}) 192.168.8.84: PROCESS_TGS: authtime 0,  <unknown client> for HTTP/XXXX, Request is a replay


I never saw these problems with GSSAPI based auth.


mod_auth_kerb seems to try to workaround the replay-cache problem and
makes some assumptions regarding krb5 internals. Can RH patches on
krb5 cause conflicts there?


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

krb5-server-1.4.1-5
mod_auth_kerb-5.0-6


How reproducible:

randomly



Additional info:

As both mod_auth_kerb and krb5 is heavily patched by RH, I do not want
to make upstream bugreports.

Apache was setup as

| <IfModule mod_auth_kerb.c>
|         <Directory />
|                 Krb5Keytab      /etc/httpd/conf/krb5.keytab
|                 KrbAuthRealms   ....
|         </Directory>
| </IfModule>
| 
| <Location /development>
| 	DAV             svn
|         SVNPath         ....
| 
|         SSLRequireSSL
|         AuthType        Kerberos
|         AuthGroupFile   /etc/httpd/conf/default-groups
|         Require group   ....
| 
|         <LimitExcept GET PROPFIND OPTIONS REPORT>
|         </LimitExcept>
| </Location>
Comment 1 Joe Orton 2005-08-09 06:03:45 EDT
We've been able to reproduce these with unpatched mod_auth_kerb too (see bug
157328) - I think it's a fundamental problem with how the Basic auth mode works.
Comment 2 Enrico Scholz 2005-08-09 06:14:58 EDT
(the mentioned bug seems to be unrelated ;))

http://comments.gmane.org/gmane.comp.apache.mod-auth-kerb.general/614 discusses
the same problem (but is a little bit out-of-context for me). They mention usage
of sizeof(k5_mutex_t) which depends on used krb5-lib and compiler flags.
Comment 3 Joe Orton 2005-08-09 06:27:30 EDT
Sorry, bug 157238.

Re: the thread you reference.  I hadn't realised that hack was actually enabled,
eww.  But I saw the replay errors when I was testing with the RHEL4 krb5-1.3.4.  

My understanding was that the error is being issued by the KDC on attempts to
verify the credentials several times very frequently - this seems to really be
an inevitable failure.
Comment 4 Enrico Scholz 2005-08-10 08:14:07 EDT
Created attachment 117599 [details]
Quick'n dirty hack with sleep and retry-as-long-we-get-errors loop

Description says it; it's a dirty hack which allows non-gssapi aware SVN
clients to work with my server.

Right fix would be probably something like using the same ccache for the same
connection/principal or even a mod_auth_kerb session. Currently it uses MEMORY:
which gets destroyed at each new authentication.

I am unexperienced in krb5 programming, so perhaps a better way is possible.
Comment 5 Christian Iseli 2007-01-22 06:09:42 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 6 petrosyan 2008-02-28 05:00:37 EST
Fedora Core 4 is no longer maintained.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.

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