First of all, you probably want to tighten the permissions on the `$CVSROOT' and `$CVSROOT/CVSROOT' directories. See section Security considerations with password authentication, for more details.
On the server side, the file `/etc/inetd.conf'
needs to be edited so
inetd knows to run the
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.
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
inetd run a shell script which then invokes
CVS with the necessary arguments.)
inetd wants a symbolic service
name instead of a raw port number, then put this in
cvspserver instead of
2401 in `inetd.conf'.
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 section Trouble making a connection to a CVS server.
Because the client stores and transmits passwords in cleartext (almost--see section Security considerations with password authentication, 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 section The 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
crypt() function, so it is possible to
paste in passwords directly from regular Unix
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
See section Read-only repository access.)
The second and third lines will grant access to
spwang if they supply their
respective plaintext passwords.
The fourth line will grant access to
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
The fifth line shows that system user identities can be
shared: any client who successfully authenticates as
qproj will actually run 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
a change to a project, the checkin is recorded in the
project's history under the name
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 section The CVSROOT/config configuration file). 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 section Security considerations with password authentication 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
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 See section The checkoutlist file.