I didn't realize it before, but the subversion server running without tunneling over ssh doesn't actually send the password in the clear when authenticating users. From the subversion book:
At the time of writing, the server only knows how to send a CRAM-MD5 authentication challenge. In essence, the server sends a bit of data to the client. The client uses the MD5 hash algorithm to create a fingerprint of the data and password combined, 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.
This makes me feel much more comfortable. So I've been switching all my repositories to use just the svn:// protocol. This means I have to run the svnserve program, since by using svn+ssh, no daemon is required.
I want to use xinetd to start the svnserve program. There was already a config file called /etc/xinetd.d/svn which would start the server. However, the path to svnserve was wrong. I changed it to look like this:
service svn
{
id = stream
socket_type = stream
protocol = tcp
user = svn
wait = no
disable = no
server = /usr/local/bin/svnserve
server_args = -i -r /svn
}
I removed the line type=INTERNAL.
Turns out you can't specify arguments to pass to the program on the server= line, you have to do it in the server_args line (which wasn't there before). Note: -r /svn makes svnserve only serve repositories under the /svn folder.
You might at some point get a "svn: Malformed header" error message. This will happen if svnserve is run by xinetd.d but not running with the -i switch.
Now that svnserve is finally running, I can configure access to each repository individually. There are details on how to do this in the Subversion Book. I wasn't able to control access on a repository-by-repository level when running with svn+ssh (aside from configuring unix users/groups, but that would be a pain.)
