On 24 okt 2012, at 15:37, Roderich Schupp wrote: > On Wed, Oct 24, 2012 at 6:09 AM, Daniel Shahaf <d...@daniel.shahaf.name> > wrote: >> Daniel Shahaf wrote on Wed, Oct 24, 2012 at 06:07:45 +0200: >>> I can't reproduce this. 'curl -s https://svn.apache.org/repos/private/' >> Since I didn't pass -u, in both cases I was browsing as an anonymous user. >>> That server runs 1.7.0. > > SVN 1.7.7 here and I tested as an authenticated user (<Location /svn> > does "require valid-user"). I'm not listed in the > AuthzSVNAccessFile and it doesn't contain any * or $special rules either.
I was able to reproduce after reconfiguring from SVNParentPath to SVNPath. - With Satisfy All (default): curl -s http://... -u username - With Satisfy Any: curl -s http://... Got similar output to what Roderich posted when authz configured such that user has no access. If this behaviour appeared in SVN 1.7, then it seems likely that we are seeing another side effect of the very change that this thread started from: i.e. the "fix" for issue 2753. That fix presumably removes authz when accessing "/" regardless whether that means the list of repositories or the root of a single repository. At minimum, this should be changed such that removal of authz on "/" only applies if referring to actual server root. That would enable hosting SVNParentPath directly on server root while reverting to 1.6 authz for the other cases: SVNParentPath in /somepath/ and SVNPath configs. Somewhat half baked since the "leak" will remain when hosting SVNParentPath directly on server root but ok for other configs. A better solution is the earlier suggestion to filter list of repositories based on actual access to the individual repositories. That would remove the non-obvious behaviours which is somewhat important with authz. regards, Thomas Å.
