There was a discussion in April 2010 regarding the "fix" for issue 2753. http://svn.haxx.se/dev/archive-2010-04/0277.shtml
Unfortunately the discussion died due to lack of other opinions. I think Mike had some very important input here and I believe that this concluding statement is incorrect: From: Kamesh Jayachandran <kamesh_at_collab.net> Date: Tue, 13 Apr 2010 00:35:11 +0530 > Whoever wanted SVNListParentPath to work with authz prior to this commit was > using a workaround of <Location /svn/> which was leaking the same info. Status in Subversion 1.6 - I have never seen the leak in 1.6 that Kamesh is referring to. - It was possible to use SVNListParentPath and authz on location /svn/ with a simple RedirectMatch ensuring that browsers end up att /svn/ rather than /svn. I might have been impossible when hosting SVNListParentPath at server root, not sure. - It was possible to restrict access to "Collection of Repositories" by controlling access to [/], while access to individual repositories were controlled by [repoN:/]. This might not have been by design, bit still a very useful feature. - It was NOT possible to display a "Collection of Repositories" filtered to display the repositories where the user has access. Status in Subversion 1.7 - The fix for issue 2753 presumably enables SVNListParentPath to work with authz on server root. By completely removing authz on Collection of Repositories (?). - It is no longer possible to protect "Collection of Repositories" from groups of users. When having "Satisfy Any", required for anonymous access (* = r), the "Collection of Repositories" is open for anonymous access. Otherwise requires authn but not authz. Use cases suffering from regression in 1.7 - The "Collection of Repositories" is leaked to all users, including for instance external consultants with access to a subset of information. There might be separate repositories for unreleased products, where leaking the repo name is undesirable. - Servers hosting multiple repositories for different customers will leak which customers are on the same server. Can likely be worked around by explicitly blocking access to "Collection of Repositories" in Apache config. - Difficult/impossible to combine anonymous access to a subset of information and requiring authentication to view "Collection of Repositories". There might be workarounds for some of the use cases, but that would involve using groups in Apache config which creates an additional location where authz must be maintained. During the 2010 discussion Mike suggested something that we (Simonsoft) would be very happy to see implemented: > In a perfect world, I would expect that requests to the parent directory > would not be authz-denied, but that each repository in the listing of > repositories would be authz-checked against the authz configuration. In > other words, say I have a parent-path with three repositories: calc, watch, > lamp. And say I have an authz file like so: > [lamp:/] > * = > I would expect that a request to the parent directory would yield a listing > that included the 'calc' and 'watch' repositories, but not the 'lamp' one. > Given that we now also have AuthzSVNReposRelativeAccessFile, there is no obvious location to define access to "Collection of Repositories". By always allowing access to "Collection of Repositories" but filtering based on whether the user has access to each repository root, there is no need to explicitly set access to "Collection of Repositories". One less piece of information to maintain. Hope this summary can spark some fresh discussion! Regards, Thomas Å.
