BSD DevCenter
oreilly.comSafari Books Online.Conferences.


CVS Mirror
Pages: 1, 2

Controlling Access

Just because you want to be a good Net citizen and have a private repository, doesn't mean that you want every yokel downloading from you. The cvsupd server allows you to control access.

The file /usr/local/etc/cvsup/cvsupd.access controls which hosts may connect. The syntax is simple: a line beginning with # denotes a comment. A + means that the client can connect, and a - means that the client cannot. A * means that the client must authenticate (see below).

Each rule in cvsupd.access can refer to either a host name or an IP address. IP addresses are preferred, for all the usual reasons. You can use netmasks with IP addresses as well.

For example, to allow access from the network and reject clients accessing from elsewhere, use this.


Simple, eh?

You can also use cvsupd.access to restrict the number of connections the system will allow at any one time. This is done by specifying a number after the network number. For example, to restrict the server to 10 connections per second you would use

-	  10

As you might guess, you can use this system to throttle connections from blocks of IP addresses.

You can also use the -C flag to cvsupd to achieve the same effect, but that requires that you kill and restart cvsupd. Changes to cvsupd.access take effect immediately.

This system works well, until you want to allow people to connect by username. If you might want to connect to your CVSup mirror from arbitrary locations, you need to use authentication.


The CVSup server uses a challenge-response system for authentication, rather than handing passwords around in clear text. If someone drops a packet sniffer on the network, the cannot grab passwords. What's more, since the challenge-response system incorporates the time, the client IP address, some pseudo-random numbers, and a bunch of other system garbage that changes rapidly, a response cannot be used a second time.

You must use a password file, /usr/local/etc/cvsup/cvsupd.passwd, to use authentication. This file should only be readable by the cvsup user, or anyone could grab user information. (You can do this by running chown cvsup cvsupd.passwd and chmod 600 cvsupd.passwd.)

Blank lines and lines beginning with # are ignored. The remaining lines are all for acceptable users.

The first line is the server name and private key, separated by a colon.

The server name is sent back to the client. The private key is used for additional randomness. You don't have to have a private key -- the cvsupd password system is pretty random as is -- but you must have the colon. The private key cannot contain a colon.

After this, you have your legitimate users. Each user appears on a separate line, in the following format.

user ID:shared secret:class:comment

Traditionally, cvsup IDs are email addresses, i.e., "" The shared secret is based upon a cryptographic hash of your chosen password. The class is reserved for future use, and should be left blank. Finally, the comment field can be used by the administrator.

The cvpasswd(1) command automates generating cvsupd.passwd entries. You use it like this:

cvpasswd userID servername

For example:

# cvpasswd
Enter password:
Enter same password again:

Send this line to the server administrator at
Be sure to send it using a secure channel!

Add this line to your file "$HOME/.cvsup/auth", replacing "XXX"
with the password you typed in:
Make sure the file is readable and writable only by you!

Well, this is pretty straightforward. Copy the first line given to /usr/local/etc/cvsup/cvsupd.passwd on the server. On your client system, create a .cvsup directory and put the second line into .cvsup/auth. Make sure that only you can read that file (chmod 600 .cvsup/auth).

CVS master John Polstra says, "A common mistake here is to put the '.cvsup' directory into the wrong user's home directory. It should be in the home directory of the user ID under which the 'cvsup' command runs. In the standard cvsup-mirror installation, that would be ~cvsupin/.cvsup/auth." There speaks a man who has answered the same question one too many times.

Combining Authentication and Access

If you want to demand that all your users authenticate, it's pretty simple. Create an empty cvsupd.access file, and build a normal cvsupd.passwd file. Requiring authentication is the standard in this case.

If you don't want to use authentication, don't create a cvsupd.passwd file.

If you have neither a cvsupd.access nor a cvsupd.passwd file, anyone can connect to your server.

If you want to allow certain users to authenticate from anywhere, but allow some networks to update no matter who is running the system, things get only slightly more complicated.

There is an implicit "authenticate" rule at the end of cvsupd.access. If your client hasn't been blocked out by an explicit "deny" rule based on IP address, you'll be allowed to authenticate. No special configuration is required.

If you're running a CVSup server behind a NAT or firewall, you probably don't have to worry about either access control or authentication. Just cvsup-mirror and go! This saves the mirror operator's resources, your own bandwidth, and generally reduces Internet traffic. And other people will be able to connect to the official mirrors just a little more easily. Besides, it will impress the other FreeBSD users just a little.

Michael W. Lucas

Read more Big Scary Daemons columns.

Return to the BSD DevCenter.

Sponsored by: