Setting Up Subversion for One or Multiple Projects
In the configuration section I mentioned the mod_authz_svn.so module, created and installed by the Subversion installation process. This module allows us to define the access control policy on a directory basis, thus increasing the level of granularity.
Why do we need a separate module to take care of directory-based access control? Couldn't we use Apache configuration primitives? The problem here is the URL passed to Apache to access a repository, which is of the form:
As we can see, only the project path and name is visible: the project's accessed directory is hidden in the numeric code. Thus, we cannot directly apply Apache Location-based access control primitives. The solution consists of delegating directory access control to the mod_authz_svn.so module, which is able to parse the numeric code and identify the accessed directory.
The mod_authz_svn.so's access control policy is specified in a plain-text file with a simple syntax. Here's the one we use for our public projects (/svn/conf/policies/public_svn_authz):
[groups] foo = john, bob bar = john, mike [/] * = r [foo:/] @foo = rw [foo:/branch/john] bob = r [foo:/branch/bob] john = r [bar:/] @bar = rw
We first define the groups of users we want to specify the policy for, then we list the access control rules. The one under the [/] section specifies that any user can read the content of any project. For each project (for example [foo:/]) we specify a global access control policy, specifying it for the inner directories. There's no need to specify an access control rule for user john in the /branch/john directory, because it's inherited from the one in the upper-level directory.
In addition, we had to specify again the different groups' composition. We should avoid replication of such configuration directives as a good security practice. This problem is solved simply by removing any AuthGroupFile directive from the project configuration files and changing the related Require directive to a Require valid-user one, thus delegating group management to the mod_authz_svn.so module.
At this point all that remains is to add the directive AuthzSVNAccessFile to the default policy files in order to tell Apache that we intend to use the mod_authz_svn.so module as an access control facility. To do so, we must specify its configuration file. Here's the one for public projects:
<Location /public> Dav svn SVNParentPath /tmp/LJ/svn/repository/public <LimitExcept GET PROPFIND OPTIONS REPORT> Order deny,allow Deny from all Allow from 127.0.0.1 Satisfy all </LimitExcept> AuthzSVNAccessFile /tmp/LJ/svn/conf/public_svn_authz </Location> <VirtualHost _default_:8081> <Location /public> Dav svn SVNParentPath /tmp/LJ/svn/repository/public Order allow,deny Allow from all <LimitExcept GET PROPFIND OPTIONS REPORT> Order deny,allow Deny from all Satisfy all </LimitExcept> AuthzSVNAccessFile /tmp/LJ/svn/conf/public_svn_authz </Location> Include /tmp/LJ/svn/conf/policies/public/* </VirtualHost>
You may ask why we didn't use the mod_authz_svn.so module before. If we hadn't any trusted subnets, we could throw away most of the Apache access control machinery and rely solely on the mod_authz_svn.so, even if this is true only from Subversion 1.0.1. But because mod_authz_svn.so's access control strategy is user-based when in the scenario with a trusted subnet, we need a mix of source-based access control and user-based access control.
Free DevOps eBooks, Videos, and more!
Regardless of where you are in your DevOps process, Linux Journal can help!
We offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, and advice & help from the expert sources like:
- Linux Journal
- New Products
- Readers' Choice Awards 2014
- Handling the workloads of the Future
- Android Candy: Google Keep
- How Can We Get Business to Care about Freedom, Openness and Interoperability?
- Days Between Dates?
- diff -u: What's New in Kernel Development
- December 2014 Issue of Linux Journal: Readers' Choice
- The Awesome Program You Never Should Use