On 1/1/14, 11:55 AM, Peter Flynn wrote: > Apparently so; and this appears to be new (recent) behaviour. Quite why svn > believes it needs to check the permissions one level above where it was told > to > go is unclear to me, but I'm sure wiser heads have thought this one through.
This is actually really old behavior. > OT but I can't see why the REPORT request didn't need authentication; but it's > moot anyway. Because the LimitExcept included REPORT. > At that point it would seem that it ought ask my client to authenticate, and > it > would prompt me for the credentials. Agreed, I've started working on fixing that, but found there are an awful lot of places where it needs fixing. So I haven't finished yet. We have a long standing history of not necessarily returning the proper HTTP result code. > I am unclear on the distinction between /etc/svn.authz and /etc/svn.auth here. > The filename I am using for AuthUserFile is /etc/svn-auth-file; I don't have > any other svn file in /etc. /etc/svn.auth was the username/password map for Basic authentication. Doesn't matter what you call it. >> Technically you don't need the AuthzSVNAccessFile either, > > In fact it doesn't work with it at all; I get > >>> $ svn up >>> Updating '.': >>> svn: E175013: Unable to connect to a repository at URL >>> 'http://xxx.xxx.xx/svn/yyyyy' >>> svn: E175013: Access to 'http://xxx.xxx.xx/svn/yyyyy' forbidden > > If I comment out AuthzSVNAccessFile, I still get > >>> $ svn up >>> Updating '.': >>> svn: E220000: Not authorized to open root of edit operation > > However, if I also comment out the SVNPathAuthz short_circuit line, it all > works correctly. If you don't remove the LimitExcept block you're going to still have those sorts of problems unless you set "SVNPathAuthz off" which I wouldn't recommend. Once you're removed the LimitExcept block (making your config similar to the config I posted), then you can start potentially removing AuthzSVNAccessFile. > Thank you very much indeed for the comprehensive explanation and a working > solution. Sure.