(cvs.info.gz) Password authentication server
(cvs.info.gz) Password authenticated
(cvs.info.gz) Password authentication client
126.96.36.199 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 ( Remote repositories) or overridden with the
CVS_CLIENT_PORT environment variable ( 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
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
If your `inetd' wants a symbolic service name instead of a raw port
number, then put this in `/etc/services':
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:
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'
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' ( 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:
(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
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
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:
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, config).
The default fallback behavior is to look in `/etc/passwd' for this
system user unless your system has PAM (Pluggable Authentication
Modules) and your CVS server executable was configured to use it at
compile time (using `./configure --enable-pam' - see the INSTALL file
for more). In this case, PAM will be consulted instead. This means
that CVS can be configured to use any password authentication source
PAM can be configured to use (possibilities include a simple UNIX
password, NIS, LDAP, and others) in its global configuration file
(usually `/etc/pam.conf' or possibly `/etc/pam.d/cvs'). See your PAM
documentation for more details on PAM configuration.
Note that PAM is an experimental feature in CVS and feedback is
encouraged. Please send a mail to one of the CVS mailing lists
(`email@example.com' or `firstname.lastname@example.org') if you use the CVS PAM
*WARNING: Using PAM gives the system administrator much more
flexibility about how CVS users are authenticated but no more security
than other methods. See below for more.*
CVS needs an "auth", "account" and "session" module in the PAM
configuration file. A typical PAM configuration would therefore have
the following lines in `/etc/pam.conf' to emulate the standard CVS
system `/etc/passwd' authentication:
cvs auth required pam_unix.so
cvs account required pam_unix.so
cvs session required pam_unix.so
The the equivalent `/etc/pam.d/cvs' would contain
auth required pam_unix.so
account required pam_unix.so
session required pam_unix.so
Some systems require a full path to the module so that `pam_unix.so'
(Linux) would become something like
`/usr/lib/security/$ISA/pam_unix.so.1' (Sun Solaris). See the
`contrib/pam' subdirectory of the CVS source distribution for further
The PAM service name given above as "cvs" is just the service name
in the default configuration and can be set using `./configure
--with-hardcoded-pam-service-name=<pam-service-name>' before compiling.
CVS can also be configured to use whatever name it is invoked as as
its PAM service name using `./configure
--without-hardcoded-pam-service-name', but this feature should not be
used if you may not have control of the name CVS will be invoked as.
Be aware, also, 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. This may be more of a problem with PAM authentication
because it is likely that the source of the system password is some
central authentication service like LDAP which is also used to
authenticate other services.
On the other hand, PAM makes it very easy to change your password
regularly. If they are given the option of a one-password system for
all of their activities, users are often more willing to change their
password on a regular basis.
In the non-PAM configuration where the password is stored in the
`CVSROOT/passwd' file, it is difficult to change passwords on a regular
basis since only administrative users (or in some cases processes that
act as an administrative user) are typically given access to modify
this file. Either there needs to be some hand-crafted web page or
set-uid program to update the file, or the update needs to be done by
submitting a request to an administrator to perform the duty by hand.
In the first case, having to remember to update a separate password on
a periodic basis can be difficult. In the second case, the manual
nature of the change will typically mean that the password will not be
changed unless it is absolutely necessary.
Note that PAM administrators should probably avoid configuring
one-time-passwords (OTP) for CVS authentication/authorization. If OTPs
are desired, the administrator may wish to encourage the use of one of
the other Client/Server access methods. See the section on
Remote repositories for a list of other methods.
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
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.
(cvs.info.gz) Password authenticated
(cvs.info.gz) Password authentication client
automatically generated byinfo2html