GNU Info

(cvs.info)Password authentication server

---

Next: Password authentication client Up: Password authenticated

---

Enter node , (file) or (file)node

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 Note: 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 sepcified in the
CVSROOT variable (Note: Remote repositories) or overridden with the
CVS_CLIENT_PORT environment variable (Note: 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.)

   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'.

   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 Note: Connection.

   Because the client stores and transmits passwords in cleartext
(almost--see Note: 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' (Note: 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 Note: 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, Note: 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 Note: 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 Note: checkoutlist.