Day-to-day, most Subversion repositories require little intervention on the part of an ad- ministrator. There are, however, a few essential skills that a good administrator needs to know to keep everything running smoothly, such as setting up user access, backing up the data in the repository, and recovering from crashes.
10.1
Controlling Access to the Repository
Subversion supplies you with a number of different repository access schemas that can be used from a Subversion client (as illustrated in Figure 10.1). Each schema represents not only a different access mechanism, but also a differing level of access control available to the administrator. The range of control varies from simply being able to use the operat- ing system’s file access controls to limit access to the whole repository using direct local repository access, to fine-grained per-directory access control via HTTP/HTTPS. Addition- ally, with all of the access methods (except direct local access), you can control whether users are allowed to access the repository through an insecure, unencrypted (albeit slightly faster) connection, or are required to access the repository through an encryption layer, such as SSH or SSL.
Subversion Client (svn) local (file://) svnserve (svn://) svnserve/ssh
(svn+ssh://) WebDAV (http://)
Subversion Repository
“svnbook” — 2005/4/14 — 14:55 — page 138 — #159
i i
138 Chapter 10 Administrating the Repository
10.1.1
Direct Access Control
Subversion repositories on your local machine can be accessed directly by using a local access schema, through afile://URL. This is a handy way to access a repository that is only going to be used by one person, or even a couple of people using the same machine. However, this method doesn’t scale up particularly well as the number of users grows. Subversion itself does not supply any sort of built-in access controls for direct repository access, so your ability to control access is limited to your operating system’s capability to control read/write access to the repository itself. Also, there is no built-in way to provide access controls of a finer grain than whether a user has read or write access to the whole repository. You can use hook scripts (see Chapter 11, “The Joy of Automation”) to provide better control, but because the user needs full filesystem access to the repository, those controls can be circumvented.
The security advantage gained from using direct access to access a repository is the lack of network access. Direct access doesn’t require you to have any sort of server process running, and requires no network ports to be opened. Therefore, if you limit repository access to direct access, there is no way for anyone to access the repository without local access to the machine. (Remember, never access a Subversion repository from a network share if you’re using Berkeley DB as your storage backend.)
10.1.2
svnserve
Access Control
An alternate to direct access is the standalone Subversion server,svnserve. It allows you to make the repository available to remote users, while retaining access that is available only to certain users. Additionally, repository access can be performed using a custom Subversion protocol (easier) or through a tunneled SSH or RSH connection (more secure). Unfortunately, access throughsvnservedoes have the same all-or-nothing limitations that direct access does, although hook scripts can still be used to limit access.
Unlike direct access, the Subversion protocol does not require you to allow filesystem access to every user, so hook script access controls are a little more secure when using the Subversion protocol—but passwords are transferred in plaintext. If you use tunneled SSH/RSH, you don’t have to worry about plaintext passwords, but you do need to provide filesystem-level access to the repository, so hook script access controls could theoretically be circumvented. In general,svnserveis not a good choice if security is a concern.
If svnserveis started with either the -ior-doptions, it will handle requests on a dedicated port, communicating over the custom Subversion access protocol. Access is provided to all users that are found in a Subversion-specific password file, pointed to by the
svnserveconfiguration file. Thesvnserveconfiguration file is namedsvnserve.conf, and is located in theconfdirectory of the repository that the file refers to (each repository has its ownsvnserve.conffile).
The
svnserve.conf
file
Thesvnserve.conffile tellssvnservehow it should handle user authentication. It is set up similar to the Subversion user configuration files (see Chapter 7, “Configuring the
10.1 Controlling Access to the Repository 139
Client”), and has a single section named[general]. In that section, there are a number of options that you can set.
If you would like to allow anonymous access to the repository, you can set up the
anon-accessoption. If you want to allow anonymous users to get files from the reposi- tory, but not commit, you can setanon-accesstoread. Or, if you want to allow anony- mous users full access to the repository, you can give them read/write access with the value write. On the other hand, if you don’t want any sort of anonymous access, set
anon-accesstonone.
Assuming you would like more than just anonymous access to the repository, you will need to set up some users with access. To tell Subversion where to find the file containing these users, you point it to the password file by setting thepassword-dbfile to the path to the password file. I’ll describe the contents of the password file shortly.
Sometimes, you will have multiple repositories that should all share the same set of users. If you would like users to be able to authenticate with all of the repositories as a single group (i.e., cached authentication with one repository allows access to the other repositories), you can set up a realm. The realm is set with thesvnserve.confoption
realm, and should be the name you would like to use for the realm (users will see this when they log in). As a word of caution, make sure you have each repository in the realm point to the same password file. Otherwise, a user’s ability to log into the realm may be dependent on which repository the user accesses first.
A completesvnserve.conffile may look something like this:
[general]
anon-access = read
password-db = /srv/svnrepos/conf/passwd realm = Very Snazzy Repositories