Built-in Authentication and Authorization
When a client connects to an svnserve process, the following things happen:
The client selects a specific repository.
The server processes the repository’s conf/svnserve.conf file and begins to enforce any authentication and authorization policies it describes.
Depending on the defined policies, one of the following may occur:
The client may be allowed to make requests anonymously, without ever receiving an authentication challenge.
The client may be challenged for authentication at any time.
If operating in tunnel mode, the client will declare itself to be already externally authenticated (typically by SSH).
The svnserve server, by default, knows only how to send a CRAM-MD5[41] authentication challenge. In essence, the server sends a small amount of data to the client. The client uses the MD5 hash algorithm to create a fingerprint of the data and password combined, and then sends the fingerprint as a response. The server performs the same computation with the stored password to verify that the result is identical. At no point does the actual password travel over the network.
If your svnserve server was built with SASL support, it not only knows how to send CRAM-MD5 challenges, but also likely knows a whole host of other authentication mechanisms. See Using svnserve with SASL to learn how to configure SASL authentication and encryption.
It’s also possible, of course, for the client to be externally authenticated via a tunnel agent, such as ssh. In that case, the server simply examines the user it’s running as and uses this name as the authenticated username. For more on this, see Tunneling over SSH.
As you’ve already guessed, a repository’s svnserve.conf file is the central mechanism
for controlling authentication and authorization policies. The file has
the same format as other configuration files (see Runtime Configuration Area): section names are marked by square
brackets ([ and ]), comments begin with hashes (#), and each section contains specific
variables that can be set (variable =
value). Let’s walk through these files and learn how to use
them.
Create a users file and realm
For now, the [general]
section of svnserve.conf has
all the variables you need. Begin by changing the values
of those variables—choose a name for a file that will contain your
usernames and passwords, and choose an authentication realm:
[general] password-db = userfile realm = example realm
The realm is a name that you
define. It tells clients which sort of “authentication
namespace” they’re connecting to; the Subversion client
displays it in the authentication prompt and uses it as a key (along
with the server’s hostname and port) for caching credentials on disk
(see Client Credentials Caching).
The password-db variable
points to a separate file that contains a list of usernames and
passwords, using the same familiar format. For example:
[users] harry = foopassword sally = barpassword
The value of password-db can
be an absolute or relative path to the users file. For many admins,
it’s easy to keep the file right in the conf/ area of the repository, alongside
svnserve.conf. On the other hand,
it’s possible you may want to have two or more repositories share the
same users file; in that case, the file should probably live in a more
public place. The repositories sharing the users file should also be
configured to have the same realm, since the list of users essentially
defines an authentication realm. Wherever the file lives, be sure to
set the file’s read and write permissions appropriately. If you know
which user(s) svnserve will run as,
restrict read access to the users file as necessary.
Set access controls
There are two more variables to set in the svnserve.conf file: they determine what
unauthenticated (anonymous) and authenticated users are allowed to do.
The variables anon-access and
auth-access can be set to the value none, read, or write. Setting the value to none prohibits both reading and writing;
read allows read-only access to the
repository, and write allows
complete read/write access to the repository. For example:
[general] password-db = userfile realm = example realm # anonymous users can only read the repository anon-access = read # authenticated users can both read and write auth-access = write
The example settings are, in fact, the default values of the variables, should you forget to define them. If you want to be even more conservative, you can block anonymous access completely:
[general] password-db = userfile realm = example realm # anonymous users aren't allowed anon-access = none # authenticated users can both read and write auth-access = write
The server process understands not only these
“blanket” access controls to the repository, but also
finer-grained access restrictions placed on specific files and
directories within the repository. To make use of this feature, you
need to define a file containing more detailed rules, and then set the
authz-db variable to point to
it:
[general] password-db = userfile realm = example realm # Specific access rules for specific locations authz-db = authzfile
We discuss the syntax of the authzfile file in detail later in Path-Based Authorization. Note that the authz-db variable isn’t mutually exclusive
with the anon-access and auth-access variables; if all the variables
are defined at once, all of the rules must be
satisfied before access is allowed.