svnserve, a Custom Server

<?xml version="1.0" encoding="utf-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>svnserve, a Custom Server</title> <link rel="stylesheet" type="text/css" href="styles.css" /> <meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /> <link rel="home" href="index.html" title="Version Control with Subversion" /> <link rel="up" href="svn.serverconfig.html" title="Chapter 6. Server Configuration" /> <link rel="prev" href="svn.serverconfig.choosing.html" title="Choosing a Server Configuration" /> <link rel="next" href="svn.serverconfig.httpd.html" title="httpd, the Apache HTTP Server" /> </head> <body> <div xmlns="" id="vcws-version-notice"> <p>This documentation was written to describe the 1.7.x series of Apache™ Subversion®. If you are running a different version of Subversion, you are strongly encouraged to visit <a href="http://www.svnbook.com/">http://www.svnbook.com/</a> and instead consult the version of this documentation appropriate for your version of Subversion.</p> </div> <div class="navheader"> <table width="100%" summary="Navigation header"> <tr> <th colspan="3" align="center">svnserve, a Custom Server</th> </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="svn.serverconfig.choosing.html">Prev</a> </td> <th width="60%" align="center">Chapter 6. Server Configuration</th> <td width="20%" align="right"> <a accesskey="n" href="svn.serverconfig.httpd.html">Next</a></td> </tr> </table> <hr /> </div> <div class="sect1"> <div class="titlepage"> <div> <div> <h2 class="title" style="clear: both"><a id="svn.serverconfig.svnserve"></a>svnserve, a Custom Server</h2> </div> </div> </div> <p>The <span class="command"><strong>svnserve</strong></span> program is a lightweight server, capable of speaking to clients over TCP/IP using a custom, stateful protocol. Clients contact an <span class="command"><strong>svnserve</strong></span> server by using URLs that begin with the <code class="literal">svn://</code> or <code class="literal">svn+ssh://</code> scheme. This section will explain the different ways of running <span class="command"><strong>svnserve</strong></span>, how clients authenticate themselves to the server, and how to configure appropriate access control to your repositories.</p> <div class="sect2"> <div class="titlepage"> <div> <div> <h3 class="title"><a id="svn.serverconfig.svnserve.invoking"></a>Invoking the Server</h3> </div> </div> </div> <p>There are a few different ways to run the <span class="command"><strong>svnserve</strong></span> program:</p> <div class="itemizedlist"> <ul class="itemizedlist" style="list-style-type: disc; "> <li class="listitem"> <p>Run <span class="command"><strong>svnserve</strong></span> as a standalone daemon, listening for requests.</p> </li> <li class="listitem"> <p>Have the Unix <span class="command"><strong>inetd</strong></span> daemon temporarily spawn <span class="command"><strong>svnserve</strong></span> whenever a request comes in on a certain port.</p> </li> <li class="listitem"> <p>Have SSH invoke a temporary <span class="command"><strong>svnserve</strong></span> over an encrypted tunnel.</p> </li> <li class="listitem"> <p>Run <span class="command"><strong>svnserve</strong></span> as a Microsoft Windows service.</p> </li> <li class="listitem"> <p>Run <span class="command"><strong>svnserve</strong></span> as a launchd job.</p> </li> </ul> </div> <p>The following sections will cover in detail these various deployment options for <span class="command"><strong>svnserve</strong></span>.</p> <div class="sect3"> <div class="titlepage"> <div> <div> <h4 class="title"><a id="svn.serverconfig.svnserve.invoking.daemon"></a>svnserve as daemon</h4> </div> </div> </div> <p>The easiest option is to run <span class="command"><strong>svnserve</strong></span> as a standalone <span class="quote">“<span class="quote">daemon</span>”</span> process. Use the <code class="option">-d</code> option for this:</p> <div class="informalexample"> <pre class="screen"> $ svnserve -d $ # svnserve is now running, listening on port 3690 </pre> </div> <p>When running <span class="command"><strong>svnserve</strong></span> in daemon mode, you can use the <code class="option">--listen-port</code> and <code class="option">--listen-host</code> options to customize the exact port and hostname to <span class="quote">“<span class="quote">bind</span>”</span> to.</p> <p>Once we successfully start <span class="command"><strong>svnserve</strong></span> as explained previously, it makes every repository on your system available to the network. A client needs to specify an <span class="emphasis"><em>absolute</em></span> path in the repository URL. For example, if a repository is located at <code class="filename">/var/svn/project1</code>, a client would reach it via <code class="uri">svn://host.example.com/var/svn/project1</code>. To increase security, you can pass the <code class="option">-r</code> option to <span class="command"><strong>svnserve</strong></span>, which restricts it to exporting only repositories below that path. For example:</p> <div class="informalexample"> <pre class="screen"> $ svnserve -d -r /var/svn … </pre> </div> <p>Using the <code class="option">-r</code> option effectively modifies the location that the program treats as the root of the remote filesystem space. Clients then use URLs that have that path portion removed from them, leaving much shorter (and much less revealing) URLs:</p> <div class="informalexample"> <pre class="screen"> $ svn checkout svn://host.example.com/project1 … </pre> </div> </div> <div class="sect3"> <div class="titlepage"> <div> <div> <h4 class="title"><a id="svn.serverconfig.svnserve.invoking.inetd"></a>svnserve via inetd</h4> </div> </div> </div> <p>If you want <span class="command"><strong>inetd</strong></span> to launch the process, you need to pass the <code class="option">-i</code> (<code class="option">--inetd</code>) option. In the following example, we've shown the output from running <code class="literal">svnserve -i</code> at the command line, but note that this isn't how you actually start the daemon; see the paragraphs following the example for how to configure <span class="command"><strong>inetd</strong></span> to start <span class="command"><strong>svnserve</strong></span>.</p> <div class="informalexample"> <pre class="screen"> $ svnserve -i ( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops d\ epth log-revprops atomic-revprops partial-replay ) ) ) </pre> </div> <p>When invoked with the <code class="option">--inetd</code> option, <span class="command"><strong>svnserve</strong></span> attempts to speak with a Subversion client via <code class="filename">stdin</code> and <code class="filename">stdout</code> using a custom protocol. This is the standard behavior for a program being run via <span class="command"><strong>inetd</strong></span>. The IANA has reserved port 3690 for the Subversion protocol, so on a Unix-like system you can add lines to <code class="filename">/etc/services</code> such as these (if they don't already exist):</p> <div class="informalexample"> <pre class="programlisting"> svn 3690/tcp # Subversion svn 3690/udp # Subversion </pre> </div> <p>If your system is using a classic Unix-like <span class="command"><strong>inetd</strong></span> daemon, you can add this line to <code class="filename">/etc/inetd.conf</code>:</p> <div class="informalexample"> <pre class="programlisting"> svn stream tcp nowait svnowner /usr/bin/svnserve svnserve -i </pre> </div> <p>Make sure <span class="quote">“<span class="quote">svnowner</span>”</span> is a user that has appropriate permissions to access your repositories. Now, when a client connection comes into your server on port 3690, <span class="command"><strong>inetd</strong></span> will spawn an <span class="command"><strong>svnserve</strong></span> process to service it. Of course, you may also want to add <code class="option">-r</code> to the configuration line as well, to restrict which repositories are exported.</p> </div> <div class="sect3"> <div class="titlepage"> <div> <div> <h4 class="title"><a id="svn.serverconfig.svnserve.invoking.tunnel"></a>svnserve over a tunnel</h4> </div> </div> </div> <p>Another way to invoke <span class="command"><strong>svnserve</strong></span> is in tunnel mode, using the <code class="option">-t</code> option. This mode assumes that a remote-service program such as <span class="command"><strong>rsh</strong></span> or <span class="command"><strong>ssh</strong></span> has successfully authenticated a user and is now invoking a private <span class="command"><strong>svnserve</strong></span> process <span class="emphasis"><em>as that user</em></span>. (Note that you, the user, will rarely, if ever, have reason to invoke <span class="command"><strong>svnserve</strong></span> with the <code class="option">-t</code> at the command line; instead, the SSH daemon does so for you.) The <span class="command"><strong>svnserve</strong></span> program behaves normally (communicating via <code class="filename">stdin</code> and <code class="filename">stdout</code>) and assumes that the traffic is being automatically redirected over some sort of tunnel back to the client. When <span class="command"><strong>svnserve</strong></span> is invoked by a tunnel agent like this, be sure that the authenticated user has full read and write access to the repository database files. It's essentially the same as a local user accessing the repository via <code class="literal">file://</code> URLs.</p> <p>This option is described in much more detail later in this chapter in <a class="xref" href="svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth" title="Tunneling over SSH">the section called “Tunneling over SSH”</a>.</p> </div> <div class="sect3"> <div class="titlepage"> <div> <div> <h4 class="title"><a id="svn.serverconfig.svnserve.invoking.winservice"></a>svnserve as a Windows service</h4> </div> </div> </div> <p>If your Windows system is a descendant of Windows NT (Windows 2000 or newer), you can run <span class="command"><strong>svnserve</strong></span> as a standard Windows service. This is typically a much nicer experience than running it as a standalone daemon with the <code class="option">--daemon</code> (<code class="option">-d</code>) option. Using daemon mode requires launching a console, typing a command, and then leaving the console window running indefinitely. A Windows service, however, runs in the background, can start at boot time automatically, and can be started and stopped using the same consistent administration interface as other Windows services.</p> <p>You'll need to define the new service using the command-line tool <span class="command"><strong>SC.EXE</strong></span>. Much like the <span class="command"><strong>inetd</strong></span> configuration line, you must specify an exact invocation of <span class="command"><strong>svnserve</strong></span> for Windows to run at startup time:</p> <div class="informalexample"> <pre class="screen"> C:\> sc create svn binpath= "C:\svn\bin\svnserve.exe --service -r C:\repos" displayname= "Subversion Server" depend= Tcpip start= auto </pre> </div> <p>This defines a new Windows service named <code class="literal">svn</code> which executes a particular <span class="command"><strong>svnserve.exe</strong></span> command when started (in this case, rooted at <code class="filename">C:\repos</code>). There are a number of caveats in the prior example, however.</p> <p>First, notice that the <span class="command"><strong>svnserve.exe</strong></span> program must always be invoked with the <code class="option">--service</code> option. Any other options to <span class="command"><strong>svnserve</strong></span> must then be specified on the same line, but you cannot add conflicting options such as <code class="option">--daemon</code> (<code class="option">-d</code>), <code class="option">--tunnel</code>, or <code class="option">--inetd</code> (<code class="option">-i</code>). Options such as <code class="option">-r</code> or <code class="option">--listen-port</code> are fine, though. Second, be careful about spaces when invoking the <span class="command"><strong>SC.EXE</strong></span> command: the <code class="literal">key= value</code> patterns must have no spaces between <code class="literal">key=</code> and must have exactly one space before the <code class="literal">value</code>. Lastly, be careful about spaces in your command line to be invoked. If a directory name contains spaces (or other characters that need escaping), place the entire inner value of <code class="literal">binpath</code> in double quotes, by escaping them:</p> <div class="informalexample"> <pre class="screen"> C:\> sc create svn binpath= "\"C:\program files\svn\bin\svnserve.exe\" --service -r C:\repos" displayname= "Subversion Server" depend= Tcpip start= auto </pre> </div> <p>Also note that the word <code class="literal">binpath</code> is misleading—its value is a <span class="emphasis"><em>command line</em></span>, not the path to an executable. That's why you need to surround it with quotes if it contains embedded spaces.</p> <p>Once the service is defined, it can be stopped, started, or queried using standard GUI tools (the Services administrative control panel), or at the command line:</p> <div class="informalexample"> <pre class="screen"> C:\> net stop svn C:\> net start svn </pre> </div> <p>The service can also be uninstalled (i.e., undefined) by deleting its definition: <strong class="userinput"><code>sc delete svn</code></strong>. Just be sure to stop the service first! The <span class="command"><strong>SC.EXE</strong></span> program has many other subcommands and options; run <strong class="userinput"><code>sc /?</code></strong> to learn more about it.</p> </div> <div class="sect3"> <div class="titlepage"> <div> <div> <h4 class="title"><a id="svn.serverconfig.svnserve.invoking.launchd"></a>svnserve as a launchd job</h4> </div> </div> </div> <p>Mac OS X (10.4 and higher) uses <span class="command"><strong>launchd</strong></span> to manage processes (including daemons) both system-wide and per-user. A <span class="command"><strong>launchd</strong></span> job is specified by parameters in an XML property list file, and the <span class="command"><strong>launchctl</strong></span> command is used to manage the lifecycle of those jobs.</p> <p>When configured to run as a <span class="command"><strong>launchd</strong></span> job, <span class="command"><strong>svnserve</strong></span> is automatically launched on demand whenever incoming Subversion <code class="literal">svn://</code> network traffic needs to be handled. This is far more convenient than a configuration which requires you to manually invoke <span class="command"><strong>svnserve</strong></span> as a long-running background process.</p> <p>To configure <span class="command"><strong>svnserve</strong></span> as a <span class="command"><strong>launchd</strong></span> job, first create a job definition file named <code class="filename">/Library/LaunchDaemons/org.apache.subversion.svnserve.plist</code>. <a class="xref" href="svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.invoking.launchd.ex-1" title="Example 6.1. A sample svnserve launchd job definition">Example 6.1, “A sample svnserve launchd job definition”</a> provides an example of such a file.</p> <div class="example"> <a id="svn.serverconfig.svnserve.invoking.launchd.ex-1"></a> <p class="title"> <strong>Example 6.1. A sample svnserve launchd job definition</strong> </p> <div class="example-contents"> <pre class="programlisting"> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>org.apache.subversion.svnserve</string> <key>ServiceDescription</key> <string>Host Subversion repositories using svn:// scheme</string> <key>ProgramArguments</key> <array> <string>/usr/bin/svnserve</string> <string>--inetd</string> <string>--root=/var/svn</string> </array> <key>UserName</key> <string>svn</string> <key>GroupName</key> <string>svn</string> <key>inetdCompatibility</key> <dict> <key>Wait</key> <false/> </dict> <key>Sockets</key> <dict> <key>Listeners</key> <array> <dict> <key>SockServiceName</key> <string>svn</string> <key>Bonjour</key> <true/> </dict> </array> </dict> </dict> </plist> </pre> </div> </div> <br class="example-break" /> <div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"> <table border="0" summary="Warning"> <tr> <td rowspan="2" align="center" valign="top" width="25"> <img alt="[Warning]" src="images/warning.png" /> </td> <th align="left">Warning</th> </tr> <tr> <td align="left" valign="top"> <p>The <span class="command"><strong>launchd</strong></span> system can be somewhat challenging to learn. Fortunately, documentation exists for the commands described in this section. For example, run <strong class="userinput"><code>man launchd</code></strong> from the command line to see the manual page for <span class="command"><strong>launchd</strong></span> itself, <strong class="userinput"><code>man launchd.plist</code></strong> to read about the job definition format, etc.</p> </td> </tr> </table> </div> <p>Once your job definition file is created, you can activate the job using <span class="command"><strong>launchctl load</strong></span>:</p> <div class="informalexample"> <pre class="screen"> $ sudo launchctl load \ -w /Library/LaunchDaemons/org.apache.subversion.svnserve.plist </pre> </div> <p>To be clear, this action doesn't actually launch <span class="command"><strong>svnserve</strong></span> yet. It simply tells <span class="command"><strong>launchd</strong></span> how to fire up <span class="command"><strong>svnserve</strong></span> when incoming networking traffic arrives on the <code class="literal">svn</code> network port; it will be terminated it after the traffic has been handled.</p> <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> <table border="0" summary="Note"> <tr> <td rowspan="2" align="center" valign="top" width="25"> <img alt="[Note]" src="images/note.png" /> </td> <th align="left">Note</th> </tr> <tr> <td align="left" valign="top"> <p>Because we want <span class="command"><strong>svnserve</strong></span> to be a system-wide daemon process, we need to use <span class="command"><strong>sudo</strong></span> to manage this job as an administrator. Note also that the <code class="literal">UserName</code> and <code class="literal">GroupName</code> keys in the definition file are optional—if omitted, the job will run as the user who loaded the job.</p> </td> </tr> </table> </div> <p>Deactivating the job is just as easy to do—use <span class="command"><strong>launchctl unload</strong></span>:</p> <div class="informalexample"> <pre class="screen"> $ sudo launchctl unload \ -w /Library/LaunchDaemons/org.apache.subversion.svnserve.plist </pre> </div> <p><span class="command"><strong>launchctl</strong></span> also provides a way for you to query the status of jobs. If the job is loaded, there will be line which matches the <code class="literal">Label</code> specified in the job definition file:</p> <div class="informalexample"> <pre class="screen"> $ sudo launchctl list | grep org.apache.subversion.svnserve - 0 org.apache.subversion.svnserve $ </pre> </div> </div> </div> <div class="sect2"> <div class="titlepage"> <div> <div> <h3 class="title"><a id="svn.serverconfig.svnserve.auth"></a>Built-in Authentication and Authorization</h3> </div> </div> </div> <p>When a client connects to an <span class="command"><strong>svnserve</strong></span> process, the following things happen:</p> <div class="itemizedlist"> <ul class="itemizedlist" style="list-style-type: disc; "> <li class="listitem"> <p>The client selects a specific repository.</p> </li> <li class="listitem"> <p>The server processes the repository's <code class="filename">conf/svnserve.conf</code> file and begins to enforce any authentication and authorization policies it describes.</p> </li> <li class="listitem"> <p>Depending on the defined policies, one of the following may occur:</p> <div class="itemizedlist"> <ul class="itemizedlist" style="list-style-type: circle; "> <li class="listitem"> <p>The client may be allowed to make requests anonymously, without ever receiving an authentication challenge.</p> </li> <li class="listitem"> <p>The client may be challenged for authentication at any time.</p> </li> <li class="listitem"> <p>If operating in tunnel mode, the client will declare itself to be already externally authenticated (typically by SSH).</p> </li> </ul> </div> </li> </ul> </div> <p>The <span class="command"><strong>svnserve</strong></span> server, by default, knows only how to send a CRAM-MD5<a href="#ftn.idm6487" class="footnote" id="idm6487"><sup class="footnote">[52]</sup></a> 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. <span class="emphasis"><em>At no point does the actual password travel over the network.</em></span></p> <p>If your <span class="command"><strong>svnserve</strong></span> 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 <a class="xref" href="svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sasl" title="Using svnserve with SASL">the section called “Using <span class="command"><strong>svnserve</strong></span> with SASL”</a> later in this chapter to learn how to configure SASL authentication and encryption.</p> <p>It's also possible, of course, for the client to be externally authenticated via a tunnel agent, such as <span class="command"><strong>ssh</strong></span>. 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 the later section, <a class="xref" href="svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth" title="Tunneling over SSH">the section called “Tunneling over SSH”</a>.</p> <p>As you've already guessed, a repository's <code class="filename">svnserve.conf</code> file is the central mechanism for controlling access to the repository. When used in conjunction with other supplemental files described in this section, this configuration file offers an administrator a complete solution for governing user authentication and authorization policies. Each of the files we'll discuss uses the format common to other configuration files (see <a class="xref" href="svn.advanced.confarea.html" title="Runtime Configuration Area">the section called “Runtime Configuration Area”</a>): section names are marked by square brackets (<code class="literal">[</code> and <code class="literal">]</code>), comments begin with hashes (<code class="literal">#</code>), and each section contains specific variables that can be set (<code class="literal">variable = value</code>). Let's walk through these files now and learn how to use them.</p> <div class="sect3"> <div class="titlepage"> <div> <div> <h4 class="title"><a id="svn.serverconfig.svnserve.auth.users"></a>Create a users file and realm</h4> </div> </div> </div> <p>For now, the <code class="literal">[general]</code> section of <code class="filename">svnserve.conf</code> 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:</p> <div class="informalexample"> <pre class="programlisting"> [general] password-db = userfile realm = example realm </pre> </div> <p>The <code class="literal">realm</code> is a name that you define. It tells clients which sort of <span class="quote">“<span class="quote">authentication namespace</span>”</span> 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 <a class="xref" href="svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache" title="Caching credentials">the section called “Caching credentials”</a>). The <code class="literal">password-db</code> variable points to a separate file that contains a list of usernames and passwords, using the same familiar format. For example:</p> <div class="informalexample"> <pre class="programlisting"> [users] harry = foopassword sally = barpassword </pre> </div> <p>The value of <code class="literal">password-db</code> can be an absolute or relative path to the users file. For many admins, it's easy to keep the file right in the <code class="filename">conf/</code> area of the repository, alongside <code class="filename">svnserve.conf</code>. 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) <span class="command"><strong>svnserve</strong></span> will run as, restrict read access to the users file as necessary.</p> </div> <div class="sect3"> <div class="titlepage"> <div> <div> <h4 class="title"><a id="svn.serverconfig.svnserve.auth.general"></a>Set access controls</h4> </div> </div> </div> <p>There are two more variables to set in the <code class="filename">svnserve.conf</code> file: they determine what unauthenticated (anonymous) and authenticated users are allowed to do. The variables <code class="literal">anon-access</code> and <code class="literal">auth-access</code> can be set to the value <code class="literal">none</code>, <code class="literal">read</code>, or <code class="literal">write</code>. Setting the value to <code class="literal">none</code> prohibits both reading and writing; <code class="literal">read</code> allows read-only access to the repository, and <code class="literal">write</code> allows complete read/write access to the repository. For example:</p> <div class="informalexample"> <pre class="programlisting"> [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 </pre> </div> <p>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:</p> <div class="informalexample"> <pre class="programlisting"> [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 </pre> </div> <p>The server process understands not only these <span class="quote">“<span class="quote">blanket</span>”</span> 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 <code class="literal">authz-db</code> variable to point to it:</p> <div class="informalexample"> <pre class="programlisting"> [general] password-db = userfile realm = example realm # Specific access rules for specific locations authz-db = authzfile </pre> </div> <p>We discuss the syntax of the <code class="filename">authzfile</code> file in detail later in this chapter, in <a class="xref" href="svn.serverconfig.pathbasedauthz.html" title="Path-Based Authorization">the section called “Path-Based Authorization”</a>. Note that the <code class="literal">authz-db</code> variable isn't mutually exclusive with the <code class="literal">anon-access</code> and <code class="literal">auth-access</code> variables; if all the variables are defined at once, <span class="emphasis"><em>all</em></span> of the rules must be satisfied before access is allowed.</p> </div> </div> <div class="sect2"> <div class="titlepage"> <div> <div> <h3 class="title"><a id="svn.serverconfig.svnserve.sasl"></a>Using <span class="command"><strong>svnserve</strong></span> with SASL</h3> </div> </div> </div> <p>For many teams, the built-in CRAM-MD5 authentication is all they need from <span class="command"><strong>svnserve</strong></span>. However, if your server (and your Subversion clients) were built with the Cyrus Simple Authentication and Security Layer (SASL) library, you have a number of authentication and encryption options available to you.</p> <div class="sidebar"> <div class="titlepage"> <div> <div> <p class="title"> <strong>What Is SASL?</strong> </p> </div> </div> </div> <p>The Cyrus Simple Authentication and Security Layer is open source software written by Carnegie Mellon University. It adds generic authentication and encryption capabilities to any network protocol, and as of Subversion 1.5 and later, both the <span class="command"><strong>svnserve</strong></span> server and <span class="command"><strong>svn</strong></span> client know how to make use of this library. It may or may not be available to you: if you're building Subversion yourself, you'll need to have at least version 2.1 of SASL installed on your system, and you'll need to make sure that it's detected during Subversion's build process. The Subversion command-line client will report the availability of Cyrus SASL when you run <strong class="userinput"><code>svn --version</code></strong>; if you're using some other Subversion client, you might need to check with the package maintainer as to whether SASL support was compiled in.</p> <p>SASL comes with a number of pluggable modules that represent different authentication systems: Kerberos (GSSAPI), NTLM, One-Time-Passwords (OTP), DIGEST-MD5, LDAP, Secure-Remote-Password (SRP), and others. Certain mechanisms may or may not be available to you; be sure to check which modules are provided.</p> <p>You can download Cyrus SASL (both code and documentation) from <a class="ulink" href="http://asg.web.cmu.edu/sasl/sasl-library.html" target="_top">http://asg.web.cmu.edu/sasl/sasl-library.html</a>.</p> </div> <p>Normally, when a subversion client connects to <span class="command"><strong>svnserve</strong></span>, the server sends a greeting that advertises a list of the capabilities it supports, and the client responds with a similar list of capabilities. If the server is configured to require authentication, it then sends a challenge that lists the authentication mechanisms available; the client responds by choosing one of the mechanisms, and then authentication is carried out in some number of round-trip messages. Even when SASL capabilities aren't present, the client and server inherently know how to use the CRAM-MD5 and ANONYMOUS mechanisms (see <a class="xref" href="svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth" title="Built-in Authentication and Authorization">the section called “Built-in Authentication and Authorization”</a>). If server and client were linked against SASL, a number of other authentication mechanisms may also be available. However, you'll need to explicitly configure SASL on the server side to advertise them.</p> <div class="sect3"> <div class="titlepage"> <div> <div> <h4 class="title"><a id="svn.serverconfig.svnserve.sasl.authn"></a>Authenticating with SASL</h4> </div> </div> </div> <p>To activate specific SASL mechanisms on the server, you'll need to do two things. First, create a <code class="literal">[sasl]</code> section in your repository's <code class="filename">svnserve.conf</code> file with an initial key-value pair:</p> <div class="informalexample"> <pre class="programlisting"> [sasl] use-sasl = true </pre> </div> <p>Second, create a main SASL configuration file called <code class="filename">svn.conf</code> in a place where the SASL library can find it—typically in the directory where SASL plug-ins are located. You'll have to locate the plug-in directory on your particular system, such as <code class="filename">/usr/lib/sasl2/</code> or <code class="filename">/etc/sasl2/</code>. (Note that this is <span class="emphasis"><em>not</em></span> the <code class="filename">svnserve.conf</code> file that lives within a repository!)</p> <p>On a Windows server, you'll also have to edit the system registry (using a tool such as <span class="command"><strong>regedit</strong></span>) to tell SASL where to find things. Create a registry key named <code class="literal">[HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL Library]</code>, and place two keys inside it: a key called <code class="literal">SearchPath</code> (whose value is a path to the directory containing the SASL <code class="filename">sasl*.dll</code> plug-in libraries), and a key called <code class="literal">ConfFile</code> (whose value is a path to the parent directory containing the <code class="filename">svn.conf</code> file you created).</p> <p>Because SASL provides so many different kinds of authentication mechanisms, it would be foolish (and far beyond the scope of this book) to try to describe every possible server-side configuration. Instead, we recommend that you read the documentation supplied in the <code class="filename">doc/</code> subdirectory of the SASL source code. It goes into great detail about every mechanism and how to configure the server appropriately for each. For the purposes of this discussion, we'll just demonstrate a simple example of configuring the DIGEST-MD5 mechanism. For example, if your <code class="filename">svn.conf</code> file contains the following:</p> <div class="informalexample"> <pre class="programlisting"> pwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: /etc/my_sasldb mech_list: DIGEST-MD5 </pre> </div> <p>you've told SASL to advertise the DIGEST-MD5 mechanism to clients and to check user passwords against a private password database located at <code class="filename">/etc/my_sasldb</code>. A system administrator can then use the <span class="command"><strong>saslpasswd2</strong></span> program to add or modify usernames and passwords in the database:</p> <div class="informalexample"> <pre class="screen"> $ saslpasswd2 -c -f /etc/my_sasldb -u realm username </pre> </div> <p>A few words of warning: first, make sure the <span class="quote">“<span class="quote">realm</span>”</span> argument to <span class="command"><strong>saslpasswd2</strong></span> matches the same realm you've defined in your repository's <code class="filename">svnserve.conf</code> file; if they don't match, authentication will fail. Also, due to a shortcoming in SASL, the common realm must be a string with no space characters. Finally, if you decide to go with the standard SASL password database, make sure the <span class="command"><strong>svnserve</strong></span> program has read access to the file (and possibly write access as well, if you're using a mechanism such as OTP).</p> <p>This is just one simple way of configuring SASL. Many other authentication mechanisms are available, and passwords can be stored in other places such as in LDAP or a SQL database. Consult the full SASL documentation for details.</p> <p>Remember that if you configure your server to only allow certain SASL authentication mechanisms, this forces all connecting clients to have SASL support as well. Any Subversion client built without SASL support (which includes all pre-1.5 clients) will be unable to authenticate. On the one hand, this sort of restriction may be exactly what you want (<span class="quote">“<span class="quote">My clients must all use Kerberos!</span>”</span>). However, if you still want non-SASL clients to be able to authenticate, be sure to advertise the CRAM-MD5 mechanism as an option. All clients are able to use CRAM-MD5, whether they have SASL capabilities or not.</p> </div> <div class="sect3"> <div class="titlepage"> <div> <div> <h4 class="title"><a id="svn.serverconfig.svnserve.sasl.encryption"></a>SASL encryption</h4> </div> </div> </div> <p>SASL is also able to perform data encryption if a particular mechanism supports it. The built-in CRAM-MD5 mechanism doesn't support encryption, but DIGEST-MD5 does, and mechanisms such as SRP actually require use of the OpenSSL library. To enable or disable different levels of encryption, you can set two values in your repository's <code class="filename">svnserve.conf</code> file:</p> <div class="informalexample"> <pre class="programlisting"> [sasl] use-sasl = true min-encryption = 128 max-encryption = 256 </pre> </div> <p>The <code class="literal">min-encryption</code> and <code class="literal">max-encryption</code> variables control the level of encryption demanded by the server. To disable encryption completely, set both values to 0. To enable simple checksumming of data (i.e., prevent tampering and guarantee data integrity without encryption), set both values to 1. If you wish to allow—but not require—encryption, set the minimum value to 0, and the maximum value to some bit length. To require encryption unconditionally, set both values to numbers greater than 1. In our previous example, we require clients to do at least 128-bit encryption, but no more than 256-bit encryption.</p> </div> </div> <div class="sect2"> <div class="titlepage"> <div> <div> <h3 class="title"><a id="svn.serverconfig.svnserve.sshauth"></a>Tunneling over SSH</h3> </div> </div> </div> <p><span class="command"><strong>svnserve</strong></span>'s built-in authentication (and SASL support) can be very handy, because it avoids the need to create real system accounts. On the other hand, some administrators already have well-established SSH authentication frameworks in place. In these situations, all of the project's users already have system accounts and the ability to <span class="quote">“<span class="quote">SSH into</span>”</span> the server machine.</p> <p>It's easy to use SSH in conjunction with <span class="command"><strong>svnserve</strong></span>. The client simply uses the <code class="literal">svn+ssh://</code> URL scheme to connect:</p> <div class="informalexample"> <pre class="screen"> $ whoami harry $ svn list svn+ssh://host.example.com/repos/project harryssh@host.example.com's password: ***** foo bar baz … </pre> </div> <p>In this example, the Subversion client is invoking a local <span class="command"><strong>ssh</strong></span> process, connecting to <code class="literal">host.example.com</code>, authenticating as the user <code class="literal">harryssh</code> (according to SSH user configuration), then spawning a private <span class="command"><strong>svnserve</strong></span> process on the remote machine running as the user <code class="literal">harryssh</code>. The <span class="command"><strong>svnserve</strong></span> command is being invoked in tunnel mode (<code class="option">-t</code>), and its network protocol is being <span class="quote">“<span class="quote">tunneled</span>”</span> over the encrypted connection by <span class="command"><strong>ssh</strong></span>, the tunnel agent. If the client performs a commit, the authenticated username <code class="literal">harryssh</code> will be used as the author of the new revision.</p> <p>The important thing to understand here is that the Subversion client is <span class="emphasis"><em>not</em></span> connecting to a running <span class="command"><strong>svnserve</strong></span> daemon. This method of access doesn't require a daemon, nor does it notice one if present. It relies wholly on the ability of <span class="command"><strong>ssh</strong></span> to spawn a temporary <span class="command"><strong>svnserve</strong></span> process, which then terminates when the network connection is closed.</p> <p>When using <code class="literal">svn+ssh://</code> URLs to access a repository, remember that it's the <span class="command"><strong>ssh</strong></span> program prompting for authentication, and <span class="emphasis"><em>not</em></span> the <span class="command"><strong>svn</strong></span> client program. That means there's no automatic password-caching going on (see <a class="xref" href="svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache" title="Caching credentials">the section called “Caching credentials”</a>). The Subversion client often makes multiple connections to the repository, though users don't normally notice this due to the password caching feature. When using <code class="literal">svn+ssh://</code> URLs, however, users may be annoyed by <span class="command"><strong>ssh</strong></span> repeatedly asking for a password for every outbound connection. The solution is to use a separate SSH password-caching tool such as <span class="command"><strong>ssh-agent</strong></span> on a Unix-like system, or <span class="command"><strong>pageant</strong></span> on Windows.</p> <p>When running over a tunnel, authorization is primarily controlled by operating system permissions to the repository's database files; it's very much the same as if Harry were accessing the repository directly via a <code class="literal">file://</code> URL. If multiple system users are going to be accessing the repository directly, you may want to place them into a common group, and you'll need to be careful about umasks (be sure to read <a class="xref" href="svn.serverconfig.multimethod.html" title="Supporting Multiple Repository Access Methods">the section called “Supporting Multiple Repository Access Methods”</a> later in this chapter). But even in the case of tunneling, you can still use the <code class="filename">svnserve.conf</code> file to block access, by simply setting <code class="literal">auth-access = read</code> or <code class="literal">auth-access = none</code>.<a href="#ftn.idm6657" class="footnote" id="idm6657"><sup class="footnote">[53]</sup></a></p> <p>You'd think that the story of SSH tunneling would end here, but it doesn't. Subversion allows you to create custom tunnel behaviors in your runtime <code class="filename">config</code> file (see <a class="xref" href="svn.advanced.confarea.html" title="Runtime Configuration Area">the section called “Runtime Configuration Area”</a>). For example, suppose you want to use RSH instead of SSH.<a href="#ftn.idm6663" class="footnote" id="idm6663"><sup class="footnote">[54]</sup></a> In the <code class="literal">[tunnels]</code> section of your <code class="filename">config</code> file, simply define it like this:</p> <div class="informalexample"> <pre class="programlisting"> [tunnels] rsh = rsh -- </pre> </div> <p>And now, you can use this new tunnel definition by using a URL scheme that matches the name of your new variable: <code class="literal">svn+rsh://host/path</code>. When using the new URL scheme, the Subversion client will actually be running the command <strong class="userinput"><code>rsh -- host svnserve -t</code></strong> behind the scenes. If you include a username in the URL (e.g., <code class="literal">svn+rsh://username@host/path</code>), the client will also include that in its command (<strong class="userinput"><code>rsh -- username@host svnserve -t</code></strong>).</p> <div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"> <table border="0" summary="Warning"> <tr> <td rowspan="2" align="center" valign="top" width="25"> <img alt="[Warning]" src="images/warning.png" /> </td> <th align="left">Warning</th> </tr> <tr> <td align="left" valign="top"> <p>Notice that when defining an RSH-based tunnel, we've added the <code class="literal">--</code> end-of-options argument to the tunnel command line. This is to prevent a malformed hostname from being treated as another option to the tunnel command. You should do the same for other tunnel programs (for example, SSH).</p> </td> </tr> </table> </div> <p>But you can define new tunneling schemes to be much more clever than that:</p> <div class="informalexample"> <pre class="programlisting"> [tunnels] joessh = $JOESSH /opt/alternate/ssh -p 29934 -- </pre> </div> <p>This example demonstrates a couple of things. First, it shows how to make the Subversion client launch a very specific tunneling binary (the one located at <code class="filename">/opt/alternate/ssh</code>) with specific options. In this case, accessing an <code class="literal">svn+joessh://</code> URL would invoke the particular SSH binary with <code class="option">-p 29934</code> as arguments—useful if you want the tunnel program to connect to a nonstandard port.</p> <p>Second, it shows how to define a custom environment variable that can override the name of the tunneling program. Setting the <code class="literal">SVN_SSH</code> environment variable is a convenient way to override the default SSH tunnel agent. But if you need to have several different overrides for different servers, each perhaps contacting a different port or passing a different set of options to SSH, you can use the mechanism demonstrated in this example. Now if we were to set the <code class="literal">JOESSH</code> environment variable, its value would override the entire value of the tunnel variable—<span class="command"><strong>$JOESSH</strong></span> would be executed instead of <strong class="userinput"><code>/opt/alternate/ssh -p 29934</code></strong>.</p> </div> <div class="sect2"> <div class="titlepage"> <div> <div> <h3 class="title"><a id="svn.serverconfig.svnserve.sshtricks"></a>SSH Configuration Tricks</h3> </div> </div> </div> <p>It's possible to control not only the way in which the client invokes <span class="command"><strong>ssh</strong></span>, but also to control the behavior of <span class="command"><strong>sshd</strong></span> on your server machine. In this section, we'll show how to control the exact <span class="command"><strong>svnserve</strong></span> command executed by <span class="command"><strong>sshd</strong></span>, as well as how to have multiple users share a single system account.</p> <div class="sect3"> <div class="titlepage"> <div> <div> <h4 class="title"><a id="svn.serverconfig.svnserve.sshtricks.setup"></a>Initial setup</h4> </div> </div> </div> <p>To begin, locate the home directory of the account you'll be using to launch <span class="command"><strong>svnserve</strong></span>. Make sure the account has an SSH public/private keypair installed, and that the user can log in via public-key authentication. Password authentication will not work, since all of the following SSH tricks revolve around using the SSH <code class="filename">authorized_keys</code> file.</p> <p>If it doesn't already exist, create the <code class="filename">authorized_keys</code> file (on Unix, typically <code class="filename">~/.ssh/authorized_keys</code>). Each line in this file describes a public key that is allowed to connect. The lines are typically of the form:</p> <div class="informalexample"> <pre class="programlisting"> ssh-dsa AAAABtce9euch… user@example.com </pre> </div> <p>The first field describes the type of key, the second field is the base64-encoded key itself, and the third field is a comment. However, it's a lesser known fact that the entire line can be preceded by a <code class="literal">command</code> field:</p> <div class="informalexample"> <pre class="programlisting"> command="program" ssh-dsa AAAABtce9euch… user@example.com </pre> </div> <p>When the <code class="literal">command</code> field is set, the SSH daemon will run the named program instead of the typical tunnel-mode <span class="command"><strong>svnserve</strong></span> invocation that the Subversion client asks for. This opens the door to a number of server-side tricks. In the following examples, we abbreviate the lines of the file as:</p> <div class="informalexample"> <pre class="programlisting"> command="program" TYPE KEY COMMENT </pre> </div> </div> <div class="sect3"> <div class="titlepage"> <div> <div> <h4 class="title"><a id="svn.serverconfig.svnserve.sshtricks.fixedcmd"></a>Controlling the invoked command</h4> </div> </div> </div> <p>Because we can specify the executed server-side command, it's easy to name a specific <span class="command"><strong>svnserve</strong></span> binary to run and to pass it extra arguments:</p> <div class="informalexample"> <pre class="programlisting"> command="/path/to/svnserve -t -r /virtual/root" TYPE KEY COMMENT </pre> </div> <p>In this example, <code class="filename">/path/to/svnserve</code> might be a custom wrapper script around <span class="command"><strong>svnserve</strong></span> which sets the umask (see <a class="xref" href="svn.serverconfig.multimethod.html" title="Supporting Multiple Repository Access Methods">the section called “Supporting Multiple Repository Access Methods”</a>). It also shows how to anchor <span class="command"><strong>svnserve</strong></span> in a virtual root directory, just as one often does when running <span class="command"><strong>svnserve</strong></span> as a daemon process. This might be done either to restrict access to parts of the system, or simply to relieve the user of having to type an absolute path in the <code class="literal">svn+ssh://</code> URL.</p> <p>It's also possible to have multiple users share a single account. Instead of creating a separate system account for each user, generate a public/private key pair for each person. Then place each public key into the <code class="filename">authorized_keys</code> file, one per line, and use the <code class="option">--tunnel-user</code> option:</p> <div class="informalexample"> <pre class="programlisting"> command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry@example.com command="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally@example.com </pre> </div> <p>This example allows both Harry and Sally to connect to the same account via public key authentication. Each of them has a custom command that will be executed; the <code class="option">--tunnel-user</code> option tells <span class="command"><strong>svnserve</strong></span> to assume that the named argument is the authenticated user. Without <code class="option">--tunnel-user</code>, it would appear as though all commits were coming from the one shared system account.</p> <p>A final word of caution: giving a user access to the server via public-key in a shared account might still allow other forms of SSH access, even if you've set the <code class="literal">command</code> value in <code class="filename">authorized_keys</code>. For example, the user may still get shell access through SSH or be able to perform X11 or general port forwarding through your server. To give the user as little permission as possible, you may want to specify a number of restrictive options immediately after the <code class="literal">command</code>:</p> <div class="informalexample"> <pre class="programlisting"> command="svnserve -t --tunnel-user=harry",no-port-forwarding,no-agent-forw arding,no-X11-forwarding,no-pty TYPE1 KEY1 harry@example.com </pre> </div> <p>Note that this all must be on one line—truly on one line—since SSH <code class="filename">authorized_keys</code> files do not even allow the conventional backslash character (<code class="literal">\</code>) for line continuation. The only reason we've shown it with a line break is to fit it on the physical page of a book.</p> </div> </div> <div class="footnotes"> <br /> <hr style="width:100; text-align:left;margin-left: 0" /> <div id="ftn.idm6487" class="footnote"> <p><a href="#idm6487" class="para"><sup class="para">[52] </sup></a>See RFC 2195.</p> </div> <div id="ftn.idm6657" class="footnote"> <p><a href="#idm6657" class="para"><sup class="para">[53] </sup></a>Note that using any sort of <span class="command"><strong>svnserve</strong></span>-enforced access control at all is a bit pointless; the user already has direct access to the repository database.</p> </div> <div id="ftn.idm6663" class="footnote"> <p><a href="#idm6663" class="para"><sup class="para">[54] </sup></a>We don't actually recommend this, since RSH is notably less secure than SSH.</p> </div> </div> </div> <div class="navfooter"> <hr /> <table width="100%" summary="Navigation footer"> <tr> <td width="40%" align="left"><a accesskey="p" href="svn.serverconfig.choosing.html">Prev</a> </td> <td width="20%" align="center"> <a accesskey="u" href="svn.serverconfig.html">Up</a> </td> <td width="40%" align="right"> <a accesskey="n" href="svn.serverconfig.httpd.html">Next</a></td> </tr> <tr> <td width="40%" align="left" valign="top">Choosing a Server Configuration </td> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> <td width="40%" align="right" valign="top"> httpd, the Apache HTTP Server</td> </tr> </table> </div> <div xmlns="" id="vcws-footer"> <hr /> <p>You are reading <em>Version Control with Subversion</em> (for Subversion 1.7), by Ben Collins-Sussman, Brian W. Fitzpatrick, and C. Michael Pilato.<br />This work is licensed under the <a href="http://creativecommons.org/licenses/by/2.0/">Creative Commons Attribution License v2.0</a>.<br />To submit comments, corrections, or other contributions to the text, please visit <a href="http://www.svnbook.com/">http://www.svnbook.com/</a>.</p> </div> </body> </html>

CINXE.COM

svnserve, a Custom Server