subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Reser <>
Subject Re: How to control access of a subversion repo subfolder via AD groups
Date Wed, 09 Jul 2014 19:56:08 GMT
On 7/7/14 3:56 AM, Ankush Grover wrote:
> I am trying to setup Subversion authentication through Active Directory
> authentication and authorization through Active Directory groups.Everything is
> working fine but the issue I am facing is when I want to restrict access to
> subdirectorys of a subversion repository. For ex: there is a repo with a name
> "ankushtest" and it has a subdirectory "test", now I want some users which are
> in AD group to be able to read or commit to subdirectory "test" only. This
> access is working fine through SVN clients like Tortoise etc.. but when I try
> to open the same on a browser, the user which has access only to subdirectory
> "test" is able to see the all the directorys or files under repo "ankushtest".
> How this is working is like that, if a user types the complete url for the
> "test" directory like" then browser
> is showing the all the files & directorys of a repo.
>  In the Apache logs I see the below warning whenever I click on the url
>" and this test directory on the
> browser shows all the files & directorys whereas this directory has only 1 file
> and a sub-directory in it.
> Mon Jul 07 14:21:47 2014] [warn] mod_dav_svn: nested Location
> '/src/ankushtest/test' hinders access to 'test1' in SVNPath Location
> '/src/ankushtest'

You should only have a single Location block for your repository.  That warning
message is telling you as much.  When you use multiple Location blocks like
this then the "/src/ankushtest" and the "/src/ankushtest/test" both are
Locations that point at the root of the repository.

The reason you're seeing this work with a Subversion client is because the
Subversion client often accesses things under the root of the repository with
opaque URLs which still go through the "/src/ankushtest" Location block rather
than the "/src/ankushtest/test" Location.

If you want to do path based access control within the repository you must use
mod_authz_svn to do this.  It knows how to handle the opaque URLs and properly
provide access control.  Beyond opaque URLs there are also requests that
provide details for child paths other than just the path the request uses in
the HTTP request-line, which is all that would be matched by Location.

Setting up mod_authz_svn is generally described in the SVN Book here:

Unfortunately, using mod_authz_svn is complicated by your desire to use AD
groups.  The group membership that Apache httpd uses is not available to
mod_authz_svn, this is just a limitation of the way Apache httpd authentication
and authorization works.

So in order to do what you want you need to provide the group membership
information to mod_authz_svn separately.  This is done by adding the [groups]
section to the AccessFile.  Obviously maintaining this by hand is tedious so
people usually automate this.

It's popular to use this tool to do that automation:

Though there are also commercial products that can do this and much more such
as WANDisco's Access Control product:

I suspect there are other commercial products that can manage this for you as
well though I'm not as familiar with their features (full disclosure I work for

If you don't go the route of a commercial product to manage this I'd suggest
that you do the following things beyond just using mod_authz_svn.

* Include the "SVNPathAuthz short_circuit" directive in your Location blocks
for SVN.  This avoids running authentication/authorization processing as
sub-requests for paths that aren't in the request-line but that must be
accessed to service the request.  The default uses much more expensive
sub-requests, which while secure for any configuration are much more expensive.
 Almost not configurations actually need the default setting.

* You mention that you're using Subversion 1.7, but Subversion 1.8 adds the
AuthzSVNGroupsFile directive that permits this group data to be in a separate
file from your access configuration.  This should make it easier to configure.

View raw message