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

Re: crash in 1.4.2 and https

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2006-11-16 18:11:55 CET

Ben Collins-Sussman wrote:
> On 11/13/06, Stefan Küng <tortoisesvn@gmail.com> 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;
 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 16 18:12:21 2006

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