ETHZ Logo ID Logo

Delegating access control to the end users



To allow a user to access a given resource a subversion server usually performs two steps: authentication and authorization. In the authentication phase the server (in our case Apache) is responsible for identifying the user as himself. In the authorization phase Subversion decides if the given user is allowed to access the specified resource.

When fine-grained permission are needed (i.e., access control is managed at directory level) the Subversion module (mod_authz_svn) offers the possibility to specify a file (AuthzSVNAccessFile /path/to/access/file) which contains a set of rules defining who can access what (see Per-Directory Access Control). The files resides on the server and modifying it (e.g., adding and removing users, changing permissions) has to be performed by a special user (the Subversion server administrator) which has access to the server machine and permission to write the authorization file.

When the users that have write access repository are trustworthy it would be preferable to give them the possibility to decide who can do what on the repository they can write to without having to involve the Subversion repository administrator.

As an example you could think to a Subversion server for students where each student has a valid account (i.e., he can be authenticated) and where each student can decide on its own who can read and write his own projects (without asking the administrator).

We present a way to allow some repository user to manage access control on his own and storing the required information in the repository itself.

Putting the access control file in the repository

The idea is to store the access file used by AuthzSVNAccessFile in the repository itself. In this example we will use for each repository a file called svnacces.


$ svn co
$ ls test
branches  svnaccess tags  trunk

The svnaccess file can then be edited by any user which has write access to the root of the repository.

Since the repository is not directly accessible on the server the file has to be made accessible to Apache after each successful commit.

This can be achieved with the following post-commit hook:



svn cat file://${REPOS}/svnaccess > ${REPOS}/svnaccess

In this way each time a commit is performed the most recent svnaccess file is written to the file system and made accessible to Apache (the AuthzSVNAccessFile directive must be then set to point the location where the file is checked out).

Avoiding problems

The operation describe above has certain risks: a user could submit a syntactically incorrect file or could lock everybody out removing all the users.

To avoid these problems we wrote a small utility (svnauthcheck) that checks the validity of the committed svnaccess files before accepting them (svnauthcheck can do a little more but for the moment let's consider just the authorization file checks).

The following pre-commit hook allows to check the syntax of the authorization files and to block erroneous submissions (the error messages of svnauthcheck are reported to the user which can then correct the problem).



if svnlook cat -t "$TXN" "$REPOS" "svnaccess" | svnauthcheck ; then
    exit 0
    exit 1

ViewVC integration

ViewVC is popular tool that allows to browse a Subversion repository with a web browser. It currently doesn't support the possibility to rely on the same permission scheme as the Subversion Apache module and supports only the classical Apache access control.

We added an option to the svnauthcheck tool to generate an Apache configuration file to be used with ViewVC containing the same information in the svnaccess file rewritten in Apache-style.

As an example the svnaccess file for the repository test

user1 = rw
user2 = rw
user3 = rw

is automatically translated to

<Location /viewvc/test/>
Require user user1
<Location /viewvc/test/public/>
Require user user1 user2 user3

Please refer to the svnauthcheck documentation for the details.

A complex example

In this section we present a complex example with fine-grained directory-based access control.


We store the configuration of our DHCP servers (around 100 subnets) in a Subversion repository. Each subnet is managed by a group or institute at our institution. In addition there is a hierarchy of administrators who should be able to access a whole set of subnets (e.g., a whole department).

Structure of the repository

Sample structure:




At the root of the repository we have the dhcpd.conf file (the main DHCPd configuration file) which includes all the subnet.conf files of the different subnets.

The global svnaccess file will be then be composed of:

In this example:
group1 = user1, user2

Behind the curtains

To be able to have a finer-grained structure we:


We presented a simple and effective way to delegate the access control of complex repositories to the users without the need of a direct access to the Subversion server.


Valid HTML 4.01! Valid CSS!