Ben Collins-Sussman wrote:
On 11/13/06, Stefan Küng <[EMAIL PROTECTED]> wrote:
What would happen if neon tries different auth methods while increasing
the 'attempt' value each time? Would that maybe cause this kind of
crash? Because as I understand, Subversion only calls
svn_auth_first_credentials() if 'attempt' is zero, but it should call
this for every 'new' auth method. I could be wrong here of course.]
I'm a bit confused here. It sounds like you're saying that both neon
and the subversion libraries each have independent, parallel
implementations of 'trying multiple auth methods'. If so, yes, that
can lead to bad things.
The design of subversion's libraries is such that different auth
methods are encapsulated in 'provider' vtables, and then when the RA
layer calls first_creds(), next_creds(), etc.... the different
providers are automatically attempted.
But, if neon has its *own* concept of trying multiple auth methods,
then yeah, that could result in some weird mis-use of svn_auth.h. I
don't remember that being the case, though...
Finally, I was able to reproduce the problem. I really was close to
giving up here.
How to reproduce:
Set up an apache server on a windows domain or one which uses
authentication with the mod_auth_sspi module against a windows domain.
The configuration should look something like this:
<Location /svn/local>
DAV svn
SVNPath C:/SVN/local
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIOfferBasic On
SSPIDomain TESTSERVER
SSPIOmitDomain on
SSPIUsernameCase lower
AuthName "Subversion"
AuthzSVNAccessFile C:/svnaccess.txt
SSLRequireSSL
Require valid-user
</Location>
But that's not enough. The user trying to access that repository must
*not* be part of the domain!
Now, here's what's happening:
neon tries to authenticate first with SSPI. It tries two times before
giving up with SSPI and falling back to basic authentication. Subversion
doesn't even know about the SSPI authentication because the auth
callbacks aren't called.
Now, when neon falls back to basic authentication, the 'attempt' param
is not 0(!) but 2, since there were already two previous authentication
attempts with SSPI. Subversion checks the 'attempt' param for 0, and
only calls svn_auth_first_credentials() if it is 0.
But because the 'attempt' param is already 2, Subversion never calls
svn_auth_first_credentials() but calls svn_auth_next_credentials()
instead, which leads to the crash.
Since there was a change between neon 0.25.x and 0.26.x which causes the
'attempt' param to be now per-session than per-request, I don't know if
this should be fixed in Subversion or neon. (that's why I'm cc'ing the
neon list).
I would propose the following fix:
Index: subversion/libsvn_ra_dav/session.c
===================================================================
--- subversion/libsvn_ra_dav/session.c (revision 22315)
+++ subversion/libsvn_ra_dav/session.c (working copy)
@@ -85,7 +85,7 @@
if (! ras->callbacks->auth_baton)
return -1;
- if (attempt == 0)
+ if ((attempt == 0)||(ras->auth_iterstate == NULL))
{
const char *realmstring;
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Index: subversion/libsvn_ra_dav/session.c
===================================================================
--- subversion/libsvn_ra_dav/session.c (revision 22315)
+++ subversion/libsvn_ra_dav/session.c (working copy)
@@ -85,7 +85,7 @@
if (! ras->callbacks->auth_baton)
return -1;
- if (attempt == 0)
+ if ((attempt == 0)||(ras->auth_iterstate == NULL))
{
const char *realmstring;
_______________________________________________
neon mailing list
[email protected]
http://mailman.webdav.org/mailman/listinfo/neon
