2.9.3.1 Setting up the server for password authentication

First of all, you probably want to tighten the permissions on the $CVSROOT and $CVSROOT/CVSROOT directories. See Password authentication security, for more details.

On the server side, the file /etc/inetd.conf needs to be edited so inetd knows to run the command cvs pserver when it receives a connection on the right port. By default, the port number is 2401; it would be different if your client were compiled with CVS_AUTH_PORT defined to something else, though. This can also be specified in the CVSROOT variable (see Remote repositories) or overridden with the CVS_CLIENT_PORT environment variable (see Environment variables).

If your inetd allows raw port numbers in /etc/inetd.conf, then the following (all on a single line in inetd.conf) should be sufficient:

2401  stream  tcp  nowait  root  /usr/local/bin/cvs
cvs -f --allow-root=/usr/cvsroot pserver

(You could also use the ‘-T’ option to specify a temporary directory.)

The ‘--allow-root’ option specifies the allowable CVSROOT directory. Clients which attempt to use a different CVSROOT directory will not be allowed to connect. If there is more than one CVSROOT directory which you want to allow, repeat the option. Unfortunately, many versions of inetd have very small limits on the number of arguments and/or the total length of the command. The usual solution to this problem is to have inetd run a shell script which then invokes CVS with the necessary arguments:

#! /bin/sh
exec /usr/local/bin/cvs -f \
     --allow-root=/repo1 \
     --allow-root=/repo2 \
     ...
     --allow-root=/repoN \
     pserver

If your inetd wants a symbolic service name instead of a raw port number, then put this in /etc/services:

cvspserver      2401/tcp

and put cvspserver instead of 2401 in inetd.conf.

If your system uses xinetd instead of inetd, the procedure is slightly different. Create a file called /etc/xinetd.d/cvspserver containing the following:

service cvspserver
{
   port        = 2401
   socket_type = stream
   protocol    = tcp
   wait        = no
   user        = root
   passenv     = PATH
   server      = /usr/local/bin/cvs
   server_args = -f --allow-root=/usr/cvsroot pserver
}

(If cvspserver is defined in /etc/services, you can omit the port line.)

Once the above is taken care of, restart your inetd, or do whatever is necessary to force it to reread its initialization files.

If you are having trouble setting this up, see Connection.

Because the client stores and transmits passwords in cleartext (almost—see Password authentication security, for details), a separate CVS password file is generally used, so people don’t compromise their regular passwords when they access the repository. This file is $CVSROOT/CVSROOT/passwd (see Intro administrative files). It uses a colon-separated format, similar to /etc/passwd on Unix systems, except that it has fewer fields: CVS username, optional password, and an optional system username for CVS to run as if authentication succeeds. Here is an example passwd file with five entries:

anonymous:
bach:ULtgRLXo7NRxs
spwang:1sOp854gDF3DY
melissa:tGX1fS8sun6rY:pubcvs
qproj:XR4EZcEs0szik:pubcvs

(The passwords are encrypted according to the standard Unix crypt() function, so it is possible to paste in passwords directly from regular Unix /etc/passwd files.)

The first line in the example will grant access to any CVS client attempting to authenticate as user anonymous, no matter what password they use, including an empty password. (This is typical for sites granting anonymous read-only access; for information on how to do the "read-only" part, see Read-only access.)

The second and third lines will grant access to bach and spwang if they supply their respective plaintext passwords.

The fourth line will grant access to melissa, if she supplies the correct password, but her CVS operations will actually run on the server side under the system user pubcvs. Thus, there need not be any system user named melissa, but there must be one named pubcvs.

The fifth line shows that system user identities can be shared: any client who successfully authenticates as qproj will actually run as pubcvs, just as melissa does. That way you could create a single, shared system user for each project in your repository, and give each developer their own line in the $CVSROOT/CVSROOT/passwd file. The CVS username on each line would be different, but the system username would be the same. The reason to have different CVS usernames is that CVS will log their actions under those names: when melissa commits a change to a project, the checkin is recorded in the project’s history under the name melissa, not pubcvs. And the reason to have them share a system username is so that you can arrange permissions in the relevant area of the repository such that only that account has write-permission there.

If the system-user field is present, all password-authenticated CVS commands run as that user; if no system user is specified, CVS simply takes the CVS username as the system username and runs commands as that user. In either case, if there is no such user on the system, then the CVS operation will fail (regardless of whether the client supplied a valid password).

The password and system-user fields can both be omitted (and if the system-user field is omitted, then also omit the colon that would have separated it from the encrypted password). For example, this would be a valid $CVSROOT/CVSROOT/passwd file:

anonymous::pubcvs
fish:rKa5jzULzmhOo:kfogel
sussman:1sOp854gDF3DY

When the password field is omitted or empty, then the client’s authentication attempt will succeed with any password, including the empty string. However, the colon after the CVS username is always necessary, even if the password is empty.

CVS can also fall back to use system authentication. When authenticating a password, the server first checks for the user in the $CVSROOT/CVSROOT/passwd file. If it finds the user, it will use that entry for authentication as described above. But if it does not find the user, or if the CVS passwd file does not exist, then the server can try to authenticate the username and password using the operating system’s user-lookup routines (this "fallback" behavior can be disabled by setting SystemAuth=no in the CVS config file, see config). Be aware, however, that falling back to system authentication might be a security risk: CVS operations would then be authenticated with that user’s regular login password, and the password flies across the network in plaintext. See Password authentication security for more on this.

Right now, the only way to put a password in the CVS passwd file is to paste it there from somewhere else. Someday, there may be a cvs passwd command.

Unlike many of the files in $CVSROOT/CVSROOT, it is normal to edit the passwd file in-place, rather than via CVS. This is because of the possible security risks of having the passwd file checked out to people’s working copies. If you do want to include the passwd file in checkouts of $CVSROOT/CVSROOT, see checkoutlist.