You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2005/08/12 03:18:04 UTC
"svn lock" crash against certain 1.1.x servers [was: Re: svn 1.2.2
tarballs are up for testing/voting]
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
Re: "svn lock" crash against certain 1.1.x servers
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>
> On Aug 12, 2005, at 7:15 AM, Branko Čibej wrote:
>
>>>
>>> It's possible the different behaviour is due to a different auth setup
>>> between the tsvn server and my server. I used httpd to require
>>> read/write auth for all access, tsvn uses mod_auth_svn and probably
>>> allows read-only access as well as read/write access.
>>>
>>>
>> D'you know, I think you're right! The damn mod_authz_svn takes it
>> upon itself to return HTTP_UNAUTHORIZED in the auth_checker hook,
>> even though it's thecking authorization, not authentication. I think
>> this is a bug in mod_authz_svn. It should be returning
>> HTTP_FORBIDDEN (as in the access_checker hook), and probably
>> shouldn't provide an auth checker at all.
>
>
>
> CEE (tigris.org) doesn't use mod_authz_svn, but a proprietary module
> called mod_auth_svn. The name is deliberately ambiguous, because it
> registers itself as both an authn and authz hook with apache. It
> performs authn by checking the basic-auth-creds against a central CEE
> database, and performs authz by checking paths against another
> central CEE database.
Indeed, I was a bit quick off the mark here. I tested with a local
svn-1.1.1 over http with mod_authz_svn configured, and I still get a
405, not a 401. So it looks like the bug is in that mod_auth_svn?
Anyway, I've decided to commit Philip's patch, which avoids all auth
caching in this situation.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn lock" crash against certain 1.1.x servers
Posted by Ben Collins-Sussman <su...@collab.net>.
On Aug 12, 2005, at 7:15 AM, Branko Čibej wrote:
>>
>> It's possible the different behaviour is due to a different auth
>> setup
>> between the tsvn server and my server. I used httpd to require
>> read/write auth for all access, tsvn uses mod_auth_svn and probably
>> allows read-only access as well as read/write access.
>>
>>
> D'you know, I think you're right! The damn mod_authz_svn takes it
> upon itself to return HTTP_UNAUTHORIZED in the auth_checker hook,
> even though it's thecking authorization, not authentication. I
> think this is a bug in mod_authz_svn. It should be returning
> HTTP_FORBIDDEN (as in the access_checker hook), and probably
> shouldn't provide an auth checker at all.
CEE (tigris.org) doesn't use mod_authz_svn, but a proprietary module
called mod_auth_svn. The name is deliberately ambiguous, because it
registers itself as both an authn and authz hook with apache. It
performs authn by checking the basic-auth-creds against a central CEE
database, and performs authz by checking paths against another
central CEE database.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn lock" crash against certain 1.1.x servers
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Justin Erenkrantz <ju...@erenkrantz.com> writes:
>
>
>
>>On Fri, Aug 12, 2005 at 05:18:04AM +0200, Branko ?ibej wrote:
>>
>>
>>>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.
>>>
>>>
>>Nothing particularly jumps out at me that would have changed between httpd
>>2.0.50 and 2.0.54 that would affect this. -- justin
>>
>>
>
>It's possible the different behaviour is due to a different auth setup
>between the tsvn server and my server. I used httpd to require
>read/write auth for all access, tsvn uses mod_auth_svn and probably
>allows read-only access as well as read/write access.
>
>
D'you know, I think you're right! The damn mod_authz_svn takes it upon
itself to return HTTP_UNAUTHORIZED in the auth_checker hook, even though
it's thecking authorization, not authentication. I think this is a bug
in mod_authz_svn. It should be returning HTTP_FORBIDDEN (as in the
access_checker hook), and probably shouldn't provide an auth checker at all.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn lock" crash against certain 1.1.x servers
Posted by Philip Martin <ph...@codematters.co.uk>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> On Fri, Aug 12, 2005 at 05:18:04AM +0200, Branko ?ibej wrote:
>> 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.
>
> Nothing particularly jumps out at me that would have changed between httpd
> 2.0.50 and 2.0.54 that would affect this. -- justin
It's possible the different behaviour is due to a different auth setup
between the tsvn server and my server. I used httpd to require
read/write auth for all access, tsvn uses mod_auth_svn and probably
allows read-only access as well as read/write access.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn lock" crash against certain 1.1.x servers [was: Re: svn 1.2.2 tarballs are up for testing/voting]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Aug 12, 2005 at 05:18:04AM +0200, Branko ?ibej wrote:
> 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.
Nothing particularly jumps out at me that would have changed between httpd
2.0.50 and 2.0.54 that would affect this. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org