Re: Authz on Collection of Repositories (was: Expansion of authz policy name leak)

To clarify what this issue is about:
Subversion 1.7 leaks repository names when configured with SVNListParentPath and AuthzSVNAccessFile. It might have been unintentional, but with Subversion 1.6 (and earlier) it was possible to control access to the repository list (Collection of Repositories) using the following section in access file: [/]

This is a quite unexpected change when upgrading an existing server to version 1.7, which is not mentioned in changes. It will suddenly provide unauthenticated access to the repository list (when Satisfy Any) or provide access to users that were not intended to have access (Satisfy All).

On 19 okt 2012, at 02:07, Daniel Shahaf wrote:

> I agree it is reasonable to want the SVNParentPath URL to display only
> repositories one has some access to.
>
> This is complicated by:
>
> - THe DAV protocol does not prompt for authentication for resources
> readable by anonymous (for this, see cmpilato's old "foo-no-anon"
> blog post).

Hmm, I failed to get any hit on that blog post (tried both Google and DuckDuckGo).

Right, previously it was possible to request authentication when accessing the repository list via the access file, e.g.:
[/]
@GroupA = r

The requirement to hide/filter the repository list will be most prevalent with server configurations that always requires authentication, typically corporate subversion servers or in the hosting use case. Anonymous access on the other hand is more prevalent in the open-source use case where the feature to hide repositories is likely very rare.

The Apache directive Satisfy Any is required in order to combine access control and anonymous access (* = r). When removing Satisfy Any (i.e. Satisfy All) Apache ensures that clients are required to authenticate in order to view the repository list. This would ensure that the repository list can be correctly filtered by mod_authz_svn.

In summary, it would not be possible to have both anonymous access and a filtered repository list on the same Apache location, but that is a relatively rare requirement and not a regression. (well, perhaps it is possible with some creative Apache config).

>
> - It's possible that someone would have r or rw access to ^/bar/baz,
> but no access at all to ^/ or ^/foo/. When this is the case, should
> that repository be listed in the SVNParentPath screen? And if it's
> listed, what should happen when the link is followed?

No, it should not be listed. In this case, the user cannot browse from repository list down to the location were access is granted anyway (since he has not access to ^/bar/).

> And if it's listed, what should happen when the link is followed?

The repository is listed in both Svn 1.7, 1.6 and earlier. Access is denied if followed. The difference is that with filtering, the link will not even be displayed. An improvement if you ask me and more consistent with how access control in the repository works.

> These are my thoughts at a high level --- i.e., user-facing level, not
> implementation level. I'm not extremely familiar with the details of
> the thread, the parentpath code, or issue #2753.

I am fairly familiar with Apache config and the typical requirements of corporate installations, but not with the code. By looking at svn log C-Mike, Philip and Kamesh might be best suited to comment on the code.

regards,
Thomas Å.
Received on 2012-10-22 17:21:23 CEST