Server Configuration
[groups]
examplehost = host.example.com
[examplehost]
ssl-client-cert-file = /path/to/my/cert.p12 ssl-client-cert-password = somepassword
Once you've set the ssl-client-cert-file and ssl-client-cert-password variables, the Subversion client can automatically respond to a client certificate challenge without prompting you. 24
Authorization Options
At this point, you've configured authentication, but not authorization. Apache is able to challenge clients and confirm identities, but it has not been told how to allow or restrict access to the clients bearing those identities. This section describes two strategies for controlling access to your repositories.
Blanket Access Control
The simplest form of access control is to authorize certain users for either read-only access to a repository, or read/ write access to a repository.
You can restrict access on all repository operations by adding the Require valid-user directive to your Lo- <cation> block. Using our previous example, this would mean that only clients that claimed to be either harry or sally, and provided the correct password for their respective username, would be allowed to do anything with the Subversion repository:
<Location /svn> DAV svn
SVNParentPath /usr/local/svn
#how to authenticate a user AuthType Basic
AuthName "Subversion repository" AuthUserFile /path/to/users/file
#only authenticated users may access the repository Require valid-user
</Location>
Sometimes you don't need to run such a tight ship. For example, Subversion's own source code repository at http://svn.collab.net/repos/svn allows anyone in the world to perform read-only repository tasks (like checking out working copies and browsing the repository with a web browser), but restricts all write operations to authenticated users. To do this type of selective restriction, you can use the Limit and LimitExcept configuration directives. Like the Location directive, these blocks have starting and ending tags, and you would nest them inside your <Location> block.
The parameters present on the Limit and LimitExcept directives are HTTP request types that are affected by that block. For example, if you wanted to disallow all access to your repository except the currently supported readonly operations, you would use the LimitExcept directive, passing the GET, PROPFIND, OPTIONS, and REPORT request type parameters. Then the previously mentioned Require valid-user directive would be placed inside the <LimitExcept> block instead of just inside the <Location> block.
<Location /svn> DAV svn
24More security-conscious folk might not want to store the client certificate password in the runtime servers file.
108
Server Configuration
SVNParentPath /usr/local/svn
#how to authenticate a user AuthType Basic
AuthName "Subversion repository" AuthUserFile /path/to/users/file
#For any operations other than these, require an authenticated user. <LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user </LimitExcept>
</Location>
These are only a few simple examples. For more in-depth information about Apache access control and the Require directive, take a look at the Security section of the Apache documentation's tutorials collection at http://httpd.apache.org/docs-2.0/misc/tutorials.html.
Per-Directory Access Control
It's possible to set up finer-grained permissions using a second Apache httpd module, mod_authz_svn. This module grabs the various opaque URLs passing from client to server, asks mod_dav_svn to decode them, and then possibly vetoes requests based on access policies defined in a configuration file.
If you've built Subversion from source code, mod_authz_svn is automatically built and installed alongside mod_dav_svn. Many binary distributions install it automatically as well. To verify that it's installed correctly, make sure it comes right after mod_dav_svn's LoadModule directive in httpd.conf:
LoadModule dav_module LoadModule dav_svn_module LoadModule authz_svn_module
modules/mod_dav.so modules/mod_dav_svn.so modules/mod_authz_svn.so
To activate this module, you need to configure your Location block to use the AuthzSVNAccessFile directive, which specifies a file containing the permissions policy for paths within your repositories. (In a moment, we'll discuss the format of that file.)
Apache is flexible, so you have the option to configure your block in one of three general patterns. To begin, choose one of these basic configuration patterns. (The examples below are very simple; look at Apache's own documentation for much more detail on Apache authentication and authorization options.)
The simplest block is to allow open access to everyone. In this scenario, Apache never sends authentication challenges, so all users are treated as “anonymous”.
Example 6.1. A sample configuration for anonymous access.
<Location /repos> DAV svn
SVNParentPath /usr/local/svn
# our access control policy AuthzSVNAccessFile /path/to/access/file
</Location>
On the opposite end of the paranoia scale, you can configure your block to demand authentication from everyone.
109
Server Configuration
All clients must supply credentials to identify themselves. Your block unconditionally requires authentication via the Require valid-user directive, and defines a means to authenticate.
Example 6.2. A sample configuration for authenticated access.
<Location /repos> DAV svn
SVNParentPath /usr/local/svn
#our access control policy AuthzSVNAccessFile /path/to/access/file
#only authenticated users may access the repository Require valid-user
#how to authenticate a user
AuthType Basic
AuthName "Subversion repository" AuthUserFile /path/to/users/file
</Location>
A third very popular pattern is to allow a combination of authenticated and anonymous access. For example, many administrators want to allow anonymous users to read certain repository directories, but want only authenticated users to read (or write) more sensitive areas. In this setup, all users start out accessing the repository anonymously. If your access control policy demands a real username at any point, Apache will demand authentication from the client. To do this, you use both the Satisfy Any and Require valid-user directives together.
Example 6.3. A sample configuration for mixed authenticated/anonymous access.
<Location /repos> DAV svn
SVNParentPath /usr/local/svn
#our access control policy AuthzSVNAccessFile /path/to/access/file
#try anonymous access first, resort to real
#authentication if necessary.
Satisfy Any
Require valid-user
# how to authenticate a user AuthType Basic
AuthName "Subversion repository" AuthUserFile /path/to/users/file
</Location>
Once your basic Location block is configured, you can create an access file and define some authorization rules in it.
The syntax of the access file is the same familiar one used by svnserve.conf and the runtime configuration files.
110
Server Configuration
Lines that start with a hash (#) are ignored. In its simplest form, each section names a repository and path within it, and the authenticated usernames are the option names within each section. The value of each option describes the user's level of access to the repository path: either r (read-only) or rw (read-write). If the user is not mentioned at all, no access is allowed.
To be more specific: the value of the section-names are either of the form [repos-name:path] or the form [path]. If you're using the SVNParentPath directive, then it's important to specify the repository names in your sections. If you omit them, then a section like [/some/dir] will match the path /some/dir in every repository. If you're using the SVNPath directive, however, then it's fine to only define paths in your sections—after all, there's only one repository.
[calc:/branches/calc/bug-142] harry = rw
sally = r
In this first example, the user harry has full read and write access on the /branches/calc/bug-142 directory in the calc repository, but the user sally has read-only access. Any other users are blocked from accessing this directory.
Of course, permissions are inherited from parent to child directory. That means that we can specify a subdirectory with a different access policy for Sally:
[calc:/branches/calc/bug-142] harry = rw
sally = r
# give sally write access only to the 'testing' subdir [calc:/branches/calc/bug-142/testing]
sally = rw
Now Sally can write to the testing subdirectory of the branch, but can still only read other parts. Harry, meanwhile, continues to have complete read-write access to the whole branch.
It's also possible to explicitly deny permission to someone via inheritance rules, by setting the username variable to nothing:
[calc:/branches/calc/bug-142] harry = rw
sally = r
[calc:/branches/calc/bug-142/secret] harry =
In this example, Harry has read-write access to the entire bug-142 tree, but has absolutely no access at all to the secret subdirectory within it.
The thing to remember is that the most specific path always matches first. The mod_authz_svn module tries to match the path itself, and then the parent of the path, then the parent of that, and so on. The net effect is that mentioning a specific path in the accessfile will always override any permissions inherited from parent directories.
By default, nobody has any access to the repository at all. That means that if you're starting with an empty file, you'll probably want to give at least read permission to all users at the root of the repository. You can do this by using the asterisk variable (*), which means “all users”:
[/]
111