You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2010/07/28 19:51:20 UTC

Re: svn commit: r980046 - /subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c

Either Bert Huijben or Julian Foad wrote on Wed, Jul 28, 2010 at 15:41:35 +0200:
> 
> 
> > -----Original Message-----
> > From: julianfoad@apache.org [mailto:julianfoad@apache.org]
> > Sent: woensdag 28 juli 2010 15:18
> > To: commits@subversion.apache.org
> > Subject: svn commit: r980046 -
> > /subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c
> > 
> > Author: julianfoad
> > Date: Wed Jul 28 13:18:28 2010
> > New Revision: 980046
> > 
> > URL: http://svn.apache.org/viewvc?rev=980046&view=rev
> > Log:
> > Add assertions in FSFS to trap an internal error that is believed to
> > have
> > occurred in real life.
> > 
> > See email from me on 2010-06-22, "FSFS error in DAV MERGE - Can't open
> > file
> > 'db/transactions/props'", <http://svn.haxx.se/dev/archive-2010-
> > 06/0327.shtml>.
> 
> I would prefer to see some error here instead of an assertion. As soon as we
> know how to trigger this bug, this will most likely be a remotely exploitable
> DOS security issue.
> 
> The knowledge that is might be remotely (ab)usable, is the exactly why you
> added the test: It can be triggered by remote users.
> 
> 
> I prefer seeing an error 500 in my logs over an httpd instance on a server
> that is crashed because we added an explicit abort() call.
> 

mod_dav_svn() could call svn_error_set_malfunction_handler() with a handler
that logs the error before abort()ing.

(@mod_dav_svn folks) Does that sound reasonable?

> 
> 	Bert 
> 
>