subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elias Gerber ...@viscomvisual.com>
Subject svn client 1.8.1: Tries to log-in forever, hammering the server, eating memory and cpu
Date Thu, 08 Aug 2013 08:18:42 GMT
Hello everyone

We have the following situation that is working fine with svn clients <= 
v1.7 in a windows-environment: Our SVN-Server is a VisualSVN-Server, 
with integration of the Windows Authentication: Clients that are within 
the windows-domain authenticate automatically using their 
windows-credentials. Clients that are not part of the domain fail to 
log-in using the windows-credentials (as svn.exe sends the local 
user-information, like 'machine\username'), then svn.exe asks the user 
to enter a username and password. Clients then enter their 
domain-username ('domain\user') and the password, so they can authenticate.

Since svn 1.8.x we experience the following:
Clients that are part of the domain can log in without any problems. 
Clients that are not part of the domain try to log-in forever using the 
local account. The server rejects those credentials - it only knows 
about domain-users, not about local users. The client does not stop to 
log in then, but tries forever: At the server we see thousands of 
rejected log-in requests, at the client we see that it uses one core of 
the cpu 100% and eats more and more memory and never (? - I killed it 
when it reached more than one Gigabyte of memory) stops.

Why do I think it is a problem of the svn client:

With svn clients <= 1.7 this scenario works against VisualSVN-Server 
2.5.x (using subversion 1.7.11) and against VisualSVNS-Server 2.6.2 and 
2.6.3 (using subversion 1.8.1): If log-in using the windows-credentials 
fails, the svn-client asks for a username and password.

With svn clients >= 1.8 the problem occurs against VisualSVN-Server 
2.5.x (subversion 1.7.11) and VisualSVN-Server 2.6.2/3 (subversion 
1.8.1), so I would like to blame the client ;)

My try to test the svn-client was a simple checkout, in the form:

svn.exe --no-auth-cache checkout https://repository/svn/repo c:\tmp

For those who know VisualSVN Server: In the server we've selected 'Use 
Windows authentication' and then checked both:
- 'Basis authentication' (Users are requested to enter their username 
and password in order to authenticate to the server) and
- 'Integrated Windows Authentication' (Windows credentials are 
automatically used to authenticate to the server).

If we remove 'Integrated Windows Authentication' every svn client, 
regardless if it is in the domain or not, asks for a username/password 
and things work fine with svn.exe v1.8.1
Passing --username and --password to svn.exe does not help: If I test using

svn.exe --no-auth-cache --username user --password pass checkout 
https://repository/svn/repo c:\tmp

I see at the server that svn.exe does not send the passed user/pass, but 
still tries to log in with the local windows credentials (regardless if 
the machine is part of the domain or not - the server receives as 
username 'machine\user' or 'domain\user').

Is it possible that something like this is going on:
The client queries the server for supported log-in methods.
The server returns "basic auth" and "windows auth"
The 1.7 client first tries windows auth, fails, and then tries basic auth.
The 1.8 client tries windows auth, and if it fails it just tries again, 
and again, and again.. maybe its expecting that windows auth should work 
anyway: The user is already logged in, so the credentials must be valid. 
But they are not if the client is not part of the domain.

Looking at the stack in process explorer reveals that svn.exe seems to 
be looping around somewhere in libapr_tsvn.dll

Thanks for any help, if you need more information I'll be glad to share.

Elias



Mime
View raw message