Sorry I did not provide all the details earlier, answers inline.
On 8 November 2011 14:04, Fuhrmann Stefan (ETAS/ESA1)
> Bostjan Skufca wrote:
> > One of our developers accidentaly stumbled upon an effective way to DoS
> > the whole server by unknowingly trying to access parts of SVN repo he was
> > not authorized for. The svnserve daemon spawned a child which replied with
> > "authorization error", but developer's client (TortoiseSVN) just created new
> > connection and tried again, in a loop. For unknown reason, it also did not close
> > previous connection and this resulted in creation of several thousand svnserve
> > processes and server crash due to exhausted RAM issue.
> Does that happen with ordinary operations like showing the log
> and checking out or is this caused by the repository browser?
> The latter will e.g. try to read the content of all immediate sub-folders.
It was a repository browser. There are only 5 immediate sub-folders on
server, or are you talking about client-side?
> Can you reproduce the problem with the command line client.
Nope, just tried with 1.7.1 client. Result:
svn: E170001: Authorization failed
> > SVN server was running in standalone mode, version 1.7.1.
> What OS are you using on the server-side?
OS is 32bit Slackware 12.2, svn 1.7.1 is compiled from sources, with
the following configure command:
./configure --prefix=$PDESTDIR_SVN \
--with-apr=/usr/local/apr --with-apr-util=/usr/local/apr \
SSL is 1.0.0e and is not used in this transaction, apr is 1.4.5 and
apr-util 1.3.12, cyrus sasl 2.1.23 is also available and potentially
used for authentication only if I am not mistaken.
> Have you tried the threaded server (-T parameter)?
> At least the extra costs per requests could be lower.
Nope and true.
> > 1.) is this a known server issue and is there a way to limit number of processes
> > svnserve creates in standalone mode? (we've switched ti xinetd currently to prevent DoS)
> > 2.) is this a known client issue?
> AFAIK, this is not a known issue. From the sound of it,
> I would expect it to be a client-induced problem. But I
> can't say whether it is the TSVN code causing the problem
> or the svn client libs used by TSVN.
To me it seems like TSVN problem on one side. I seems like TSVN is not
honouring authorization error correctly but keeps trying.
Authentication is successfull here, ftr.
The other problem is server-side because there is no configurable
limit on number of spawned server processes, but this is not relevant
on this list.
Thanks for the response.
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-11-08 15:55:12 CET