[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

"svn lock" crash against certain 1.1.x servers [was: Re: svn 1.2.2 tarballs are up for testing/voting]

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-08-12 05:18:04 CEST

O.K., here's the repro provided by Stefan again, for the record:

   svn co http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/API test
   cd test
   svn lock Doxyfile

The client will ask for credentials several times (once for each
provider?), then crash.

The direct cause of the crash is in svn_auth_save_credentials, where the
provider index in the incoming svn_auth_iterstate_t is out of bounds,
and we don't do any bounds checking before pulling stuff from the
providers array. This part is easily fixed -- I'm testing the following
patch:

Index: subversion/libsvn_subr/auth.c
===================================================================
--- subversion/libsvn_subr/auth.c (revision 15686)
+++ subversion/libsvn_subr/auth.c (working copy)
@@ -314,16 +314,19 @@
     return SVN_NO_ERROR;

   /* First, try to save the creds using the provider that produced them. */
- provider = APR_ARRAY_IDX (state->table->providers,
- state->provider_idx,
- svn_auth_provider_object_t *);
- if (provider->vtable->save_credentials)
- SVN_ERR (provider->vtable->save_credentials (&save_succeeded,
- creds,
- provider->provider_baton,
- auth_baton->parameters,
- state->realmstring,
- pool));
+ if (state->table->providers->nelts > state->provider_idx)
+ {
+ provider = APR_ARRAY_IDX (state->table->providers,
+ state->provider_idx,
+ svn_auth_provider_object_t *);
+ if (provider->vtable->save_credentials)
+ SVN_ERR (provider->vtable->save_credentials (&save_succeeded,
+ creds,
+ provider->provider_baton,
+ auth_baton->parameters,
+ state->realmstring,
+ pool));
+ }
   if (save_succeeded)
     return SVN_NO_ERROR;

But I think the root of the problem is that the tigris.org server
(httpd-2.0.50/svn-1.1.1 + patches) returns 401
(Unauthorized/Authentication Required) when it sees the LOCK that it
can't handle, instead of returning 405 (Method Not Allowed). Because of
that, Neon will keep retrying with new auth data until we run out of
providers, then return NE_ERROR -- not NE_AUTH -- which we don't handle
specially, so we end up calling svn_ra_dav__maybe_store_auth_info.

I don't think we can do anything about the repeated authn prompts --
IMHO they're caused by a server bug. I verified that this doesn't happen
with httpd-2.0.54/svn-1.1.1 on Windows, and IIRC Philip verified
httpd-2.0.54/svn-1.1.4 on *nix.

Can (or should) we do something about the NE_ERROR in
svn_ra_dav__convert_error and/or
svn_ra_dav__maybe_store_auth_info_after_result?

Branko Čibej wrote:

> steveking wrote:
>
>> Branko Čibej wrote:
>>
>>> So, whatever it is, it's either fixed on trunk, or the repro isn't
>>> complete.
>>
>>
>>
>> It's not necessary to delete the auth cache. Ben Collins-Sussman
>> explained to me that if the server doesn't know the lock command,
>> Apache doesn't know that and assumes that the auth failed. So it's
>> not important that the auth cache is cleared or what
>> username/password you enter. It will always be rejected.
>
>
> That's obviously not true. As I said, the trunk build caches the auth
> info even when the lock request fails. I think 1.2.0 doesn't, though.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 12 05:19:18 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.