(cvs.info.gz) Password authentication server

Info Catalog

(cvs.info.gz) Password authenticated

(cvs.info.gz) Password authentication client

 
 2.9.4.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 ( 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
 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'.
 
    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' ( 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,  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
 (`info-cvs@gnu.org' or `bug-cvs@gnu.org') if you use the CVS PAM
 support.
 
    *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
 example configurations.
 
    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
 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.
 

Info Catalog

(cvs.info.gz) Password authenticated

(cvs.info.gz) Password authentication client