| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
First of all, you probably want to tighten the permissions on the `$CVSROOT' and `$CVSROOT/CVSROOT' directories. See 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
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 section Remote repositories) or overridden with the CVS_CLIENT_PORT
environment variable (see section All environment variables which affect CVS).
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 Trouble making a connection to a CVS server.
Because the client stores and transmits passwords in cleartext (almost--see 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
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 repository 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 section The CVSROOT/config configuration file).
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@nongnu.org or bug-cvs@nongnu.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 Security considerations with password authentication 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 see section 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 The checkoutlist file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on September, 14 2007 using texi2html 1.76.