Essential CVS/CVS Administration/Remote Repositories

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(Initial conversion from Docbook)
(Initial conversion from Docbook)
Line 87: Line 87:
If ''local'' access mode is being used on a single-user computer, security normally is not an issue. On shared filesystems or mainframes, your repository security problems are the same as the usual security issues for file sharing. Use the security services of your operating system to secure a shared repository that is accessed with the ''local'' method.
If ''local'' access mode is being used on a single-user computer, security normally is not an issue. On shared filesystems or mainframes, your repository security problems are the same as the usual security issues for file sharing. Use the security services of your operating system to secure a shared repository that is accessed with the ''local'' method.
-
[[Essential CVS/Remote Repositories#cvs-CHP-8-EX-1|Example 8-1]] shows how to check out a sandbox using the ''local'' access method.
+
[[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-1|Example 8-1]] shows how to check out a sandbox using the ''local'' access method.
<div id="cvs-CHP-8-EX-1">
<div id="cvs-CHP-8-EX-1">
Line 122: Line 122:
The ''rsh'' (or ''rsh''-like) program starts the ''cvs'' executable on the server computer, using the username and permissions of the user the ''rsh'' program has connected as. Any programs CVS calls (such as programs called from a scripting file) run with this username and access.
The ''rsh'' (or ''rsh''-like) program starts the ''cvs'' executable on the server computer, using the username and permissions of the user the ''rsh'' program has connected as. Any programs CVS calls (such as programs called from a scripting file) run with this username and access.
-
As a trouble-prevention measure, before trying to use your ''rsh'' or ''rsh''-like program with CVS, attempt to log into the server with it, using the ''program [-b] [-l username] host commands''command format, as shown in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-2|Example 8-2]].
+
As a trouble-prevention measure, before trying to use your ''rsh'' or ''rsh''-like program with CVS, attempt to log into the server with it, using the ''program [-b] [-l username] host commands''command format, as shown in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-2|Example 8-2]].
<div id="cvs-CHP-8-EX-2">
<div id="cvs-CHP-8-EX-2">
Line 137: Line 137:
Neither the ''rsh'' nor the ''server'' methods use encryption, and both transmit a clear-text username and password to a valid user account on the repository server. For this reason, I strongly recommend you use SSH or some other secured connection whenever you connect across an untrusted network. You should consider using a secured connection even on a trusted network. If there is any external connection to your network (even through a firewall), I recommend encrypting the connection.
Neither the ''rsh'' nor the ''server'' methods use encryption, and both transmit a clear-text username and password to a valid user account on the repository server. For this reason, I strongly recommend you use SSH or some other secured connection whenever you connect across an untrusted network. You should consider using a secured connection even on a trusted network. If there is any external connection to your network (even through a firewall), I recommend encrypting the connection.
-
[[Essential CVS/Remote Repositories#cvs-CHP-8-EX-3|Example 8-3]] shows how to check out a sandbox using the ''ext'' access method.
+
[[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-3|Example 8-3]] shows how to check out a sandbox using the ''ext'' access method.
<div id="cvs-CHP-8-EX-3">
<div id="cvs-CHP-8-EX-3">
Line 163: Line 163:
=== The server Access Method ===
=== The server Access Method ===
-
The ''server'' access method uses a version of ''rsh'' internal to CVS. The''.rhosts'' file on the server must be set, as described in [[Essential CVS/Remote Repositories#rsh|Section 8.3.1]] of this chapter.
+
The ''server'' access method uses a version of ''rsh'' internal to CVS. The''.rhosts'' file on the server must be set, as described in [[Essential CVS/CVS Administration/Remote Repositories#rsh|Section 8.3.1]] of this chapter.
-
To determine whether the ''server'' access method is available you can attempt to check out a sandbox with the method, as shown in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-4|Example 8-4]].
+
To determine whether the ''server'' access method is available you can attempt to check out a sandbox with the method, as shown in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-4|Example 8-4]].
<div id="cvs-CHP-8-EX-4">
<div id="cvs-CHP-8-EX-4">
Line 188: Line 188:
# Ensure that the user has a username and password for the server as well as the client.
# Ensure that the user has a username and password for the server as well as the client.
# Generate an SSH key for the client, using the key-generation program. You may add the key to the user's home directory on the server, as explained in the documentation for your SSH program. If you do so, the user won't need to provide a password when connecting with SSH. This step is optional.
# Generate an SSH key for the client, using the key-generation program. You may add the key to the user's home directory on the server, as explained in the documentation for your SSH program. If you do so, the user won't need to provide a password when connecting with SSH. This step is optional.
-
# Test whether the connection works by attempting to log in to the server with the username from step 3, as shown in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-5|Example 8-5]].
+
# Test whether the connection works by attempting to log in to the server with the username from step 3, as shown in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-5|Example 8-5]].
# Put the name of your SSH program (or its path) into the ''CVS_RSH'' environment variable on the client computer.
# Put the name of your SSH program (or its path) into the ''CVS_RSH'' environment variable on the client computer.
-
# Run CVS using''ext'' as the method in the repository path, as shown in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-3|Example 8-3]].
+
# Run CVS using''ext'' as the method in the repository path, as shown in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-3|Example 8-3]].
-
[[Essential CVS/Remote Repositories#cvs-CHP-8-EX-5|Example 8-5]] shows a test connection to a server with an SSH client program, as described in step 5.
+
[[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-5|Example 8-5]] shows a test connection to a server with an SSH client program, as described in step 5.
<div id="cvs-CHP-8-EX-5">
<div id="cvs-CHP-8-EX-5">
Line 218: Line 218:
If you wish to use Kerberos with CVS, you can use the Kerberos version of ''rsh'' to connect using the ''ext'' method. If you wish to use Kerberos more directly, use the ''kserver'' or ''gserver'' access methods.
If you wish to use Kerberos with CVS, you can use the Kerberos version of ''rsh'' to connect using the ''ext'' method. If you wish to use Kerberos more directly, use the ''kserver'' or ''gserver'' access methods.
-
If you need to call ''rsh'' or ''ssh'' with an option, write a shell script like the one in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-6|Example 8-6]] and put the path to that shell script in your''CVS_RSH'' variable. CVS will invoke the shell script, which in turn will invoke ''rsh'' or ''ssh'' with the options you desire.
+
If you need to call ''rsh'' or ''ssh'' with an option, write a shell script like the one in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-6|Example 8-6]] and put the path to that shell script in your''CVS_RSH'' variable. CVS will invoke the shell script, which in turn will invoke ''rsh'' or ''ssh'' with the options you desire.
<div id="cvs-CHP-8-EX-6">
<div id="cvs-CHP-8-EX-6">
Line 231: Line 231:
The''fork'' access method acts like''ext'' without the external connection. You can use it only when the repository and the sandbox are on the same computer. ''fork'' makes CVS run in client/server mode and is most useful for debugging — to isolate whether a fault is in CVS's remote protocols or in the networking — but it is also used as a substitute for the ''local'' method.
The''fork'' access method acts like''ext'' without the external connection. You can use it only when the repository and the sandbox are on the same computer. ''fork'' makes CVS run in client/server mode and is most useful for debugging — to isolate whether a fault is in CVS's remote protocols or in the networking — but it is also used as a substitute for the ''local'' method.
-
The ''fork'' method uses the ''CVS_SERVER'' environment variable, as described in [[Essential CVS/Remote Repositories#The ext and server Access Methods|Section 8.3]] earlier in this chapter.
+
The ''fork'' method uses the ''CVS_SERVER'' environment variable, as described in [[Essential CVS/CVS Administration/Remote Repositories#The ext and server Access Methods|Section 8.3]] earlier in this chapter.
The repository path format for ''fork'' is:
The repository path format for ''fork'' is:
Line 242: Line 242:
Security normally is not an issue with the ''fork'' access method if the method is used on a single-user computer. However, be aware of the security issues of shared filesystems or shared mainframes; use the security services of your operating system to secure a shared repository that is accessed with the ''fork'' method.
Security normally is not an issue with the ''fork'' access method if the method is used on a single-user computer. However, be aware of the security issues of shared filesystems or shared mainframes; use the security services of your operating system to secure a shared repository that is accessed with the ''fork'' method.
-
[[Essential CVS/Remote Repositories#cvs-CHP-8-EX-7|Example 8-7]] shows how to check out a sandbox using the ''fork'' access method.
+
[[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-7|Example 8-7]] shows how to check out a sandbox using the ''fork'' access method.
<div id="cvs-CHP-8-EX-7">
<div id="cvs-CHP-8-EX-7">
Line 267: Line 267:
The default port for ''gserver'' is 2401. If ''user'' is not specified, the client sends the username of the calling user on the client computer.
The default port for ''gserver'' is 2401. If ''user'' is not specified, the client sends the username of the calling user on the client computer.
-
The CVS client and server must both be compiled to run the GSS-API. If you intend to encrypt the data stream, you also need to have encryption enabled at compile time. You can test whether your CVS program has the GSS-API compiled by attempting to check out a sandbox. [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-8|Example 8-8]] shows the result when CVS does not support the GSS-API.
+
The CVS client and server must both be compiled to run the GSS-API. If you intend to encrypt the data stream, you also need to have encryption enabled at compile time. You can test whether your CVS program has the GSS-API compiled by attempting to check out a sandbox. [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-8|Example 8-8]] shows the result when CVS does not support the GSS-API.
<div id="cvs-CHP-8-EX-8">
<div id="cvs-CHP-8-EX-8">
Line 278: Line 278:
</div>
</div>
-
You can test for encryption support by checking the options list, as shown in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-9|Example 8-9]].
+
You can test for encryption support by checking the options list, as shown in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-9|Example 8-9]].
<div id="cvs-CHP-8-EX-9">
<div id="cvs-CHP-8-EX-9">
Line 327: Line 327:
cvs -ax
cvs -ax
-
To support the ''gserver'' access method, CVS needs to run a server on the computer that hosts the repository. CVS uses most of the same code to support the ''gserver'' and ''pserver'' methods. To configure the repository to run the CVS server, edit ''inetd.conf'' and add ''cvs pserver'' (not ''gserver''). See [[Essential CVS/Remote Repositories#Using inetd with gserver, kserver, and pserver|Section 8.8]] of this chapter for more information on this configuration.
+
To support the ''gserver'' access method, CVS needs to run a server on the computer that hosts the repository. CVS uses most of the same code to support the ''gserver'' and ''pserver'' methods. To configure the repository to run the CVS server, edit ''inetd.conf'' and add ''cvs pserver'' (not ''gserver''). See [[Essential CVS/CVS Administration/Remote Repositories#Using inetd with gserver, kserver, and pserver|Section 8.8]] of this chapter for more information on this configuration.
Install and configure Kerberos 5, per the instructions for your Kerberos system. The principal name for CVS is ''cvs/HOSTNAME'', where ''HOSTNAME'' is the canonical name of the host.
Install and configure Kerberos 5, per the instructions for your Kerberos system. The principal name for CVS is ''cvs/HOSTNAME'', where ''HOSTNAME'' is the canonical name of the host.
Line 341: Line 341:
The extent to which the GSS-API is secure depends on the particular system you choose and whether you choose to authenticate or encrypt the message stream. It's useful because of that flexibility; you can determine precisely which level of security you want. At present, the only system available to work with the GSS-API and CVS is Kerberos 5, which provides a high level of authentication security across an untrusted network, if the hosts connecting through it are secure.
The extent to which the GSS-API is secure depends on the particular system you choose and whether you choose to authenticate or encrypt the message stream. It's useful because of that flexibility; you can determine precisely which level of security you want. At present, the only system available to work with the GSS-API and CVS is Kerberos 5, which provides a high level of authentication security across an untrusted network, if the hosts connecting through it are secure.
-
Once the GSS-API and Kerberos 5 are installed and configured and CVS is recompiled, you can get a Kerberos ticket for your user on the client and then run CVS commands normally. [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-10|Example 8-10]] shows how to check out a sandbox using the ''gserver'' access method.
+
Once the GSS-API and Kerberos 5 are installed and configured and CVS is recompiled, you can get a Kerberos ticket for your user on the client and then run CVS commands normally. [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-10|Example 8-10]] shows how to check out a sandbox using the ''gserver'' access method.
<div id="cvs-CHP-8-EX-10">
<div id="cvs-CHP-8-EX-10">
Line 370: Line 370:
The default port for ''kserver'' is 1999. If ''user'' is not specified, the client sends the username of the calling user on the client computer.
The default port for ''kserver'' is 1999. If ''user'' is not specified, the client sends the username of the calling user on the client computer.
-
The CVS client and server must both be compiled to run Kerberos 4. If you intend to encrypt the data stream, you also need to have encryption enabled at compile time. You can test whether your CVS program has compiled ''kserver'' support by checking the command list, as shown in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-11|Example 8-11]].
+
The CVS client and server must both be compiled to run Kerberos 4. If you intend to encrypt the data stream, you also need to have encryption enabled at compile time. You can test whether your CVS program has compiled ''kserver'' support by checking the command list, as shown in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-11|Example 8-11]].
<div id="cvs-CHP-8-EX-11">
<div id="cvs-CHP-8-EX-11">
Line 387: Line 387:
</div>
</div>
-
You can test for encryption support by checking the options list, as shown earlier in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-9|Example 8-9]].
+
You can test for encryption support by checking the options list, as shown earlier in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-9|Example 8-9]].
To use CVS with ''kserver'', install and configure Kerberos 4 as described in your Kerberos manual. You need to have the header files for Kerberos 4 available for CVS to link to. The principal name for CVS is ''cvs''.
To use CVS with ''kserver'', install and configure Kerberos 4 as described in your Kerberos manual. You need to have the header files for Kerberos 4 available for CVS to link to. The principal name for CVS is ''cvs''.
Line 399: Line 399:
</div>
</div>
-
CVS needs to run a server on the repository computer to support the ''kserver'' access method. Edit ''inetd.conf'' and add a line for ''cvs kserver''. See [[Essential CVS/Remote Repositories#Using inetd with gserver, kserver, and pserver|Section 8.8]] of this chapter for details on how to edit ''inetd.conf''.
+
CVS needs to run a server on the repository computer to support the ''kserver'' access method. Edit ''inetd.conf'' and add a line for ''cvs kserver''. See [[Essential CVS/CVS Administration/Remote Repositories#Using inetd with gserver, kserver, and pserver|Section 8.8]] of this chapter for details on how to edit ''inetd.conf''.
Using Kerberos 4, CVS can encrypt the data stream, but it does not do this by default. Use the ''-x''option to encrypt the data stream. You may want to include this option in your ''.cvsrc'' file. For example:
Using Kerberos 4, CVS can encrypt the data stream, but it does not do this by default. Use the ''-x''option to encrypt the data stream. You may want to include this option in your ''.cvsrc'' file. For example:
Line 405: Line 405:
cvs -x
cvs -x
-
To run CVS, get a Kerberos ticket for the user on your client; then call CVS the usual way with the ''kserver'' method. [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-12|Example 8-12]] shows how to check out a sandbox using the ''kserver'' access method.
+
To run CVS, get a Kerberos ticket for the user on your client; then call CVS the usual way with the ''kserver'' method. [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-12|Example 8-12]] shows how to check out a sandbox using the ''kserver'' access method.
<div id="cvs-CHP-8-EX-12">
<div id="cvs-CHP-8-EX-12">
Line 423: Line 423:
To use ''pserver'', you need a username on the repository computer, to enable CVS to run programs on that computer. You may share this username (your ''system username'') with other users and have a separate ''CVS username'' to identify you to CVS as an individual. You also need to log in before running other commands.
To use ''pserver'', you need a username on the repository computer, to enable CVS to run programs on that computer. You may share this username (your ''system username'') with other users and have a separate ''CVS username'' to identify you to CVS as an individual. You also need to log in before running other commands.
-
To support the ''pserver'' access method, CVS needs to run a server on the computer that hosts the repository. To configure the repository to run the CVS server, edit ''inetd.conf'' and add ''cvs pserver''. See [[Essential CVS/Remote Repositories#Using inetd with gserver, kserver, and pserver|Section 8.8]] of this chapter for more information on ''inetd'' configuration.
+
To support the ''pserver'' access method, CVS needs to run a server on the computer that hosts the repository. To configure the repository to run the CVS server, edit ''inetd.conf'' and add ''cvs pserver''. See [[Essential CVS/CVS Administration/Remote Repositories#Using inetd with gserver, kserver, and pserver|Section 8.8]] of this chapter for more information on ''inetd'' configuration.
The repository path format for ''pserver'' is:
The repository path format for ''pserver'' is:
Line 432: Line 432:
The default port for ''pserver'' is 2401. If the user is not specified, the client sends the username of the calling user on the client computer.
The default port for ''pserver'' is 2401. If the user is not specified, the client sends the username of the calling user on the client computer.
-
You need to configure the ''passwd'' file and possibly the ''readers'' and ''writers'' files before you can use ''pserver''. These files are explained in [[Essential CVS/Remote Repositories#The passwd File|Section 8.7.1]] and [[Essential CVS/Remote Repositories#The readers and writers Files|Section 8.7.2]] of this chapter. You also need to use the ''login'' command, explained in [[Essential CVS/Remote Repositories#login and logout|Section 8.7.3]] ''.''
+
You need to configure the ''passwd'' file and possibly the ''readers'' and ''writers'' files before you can use ''pserver''. These files are explained in [[Essential CVS/CVS Administration/Remote Repositories#The passwd File|Section 8.7.1]] and [[Essential CVS/CVS Administration/Remote Repositories#The readers and writers Files|Section 8.7.2]] of this chapter. You also need to use the ''login'' command, explained in [[Essential CVS/CVS Administration/Remote Repositories#login and logout|Section 8.7.3]] ''.''
<div class="warning">
<div class="warning">
Line 442: Line 442:
</div>
</div>
-
Once CVS is configured for ''pserver'', you can check out a sandbox or use other CVS commands normally, using the ''pserver'' repository path when necessary. [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-13|Example 8-13]] shows how to check out a sandbox using the ''pserver'' access method.
+
Once CVS is configured for ''pserver'', you can check out a sandbox or use other CVS commands normally, using the ''pserver'' repository path when necessary. [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-13|Example 8-13]] shows how to check out a sandbox using the ''pserver'' access method.
<div id="cvs-CHP-8-EX-13">
<div id="cvs-CHP-8-EX-13">
Line 473: Line 473:
If the ''password'' field is empty, the user automatically authenticates even with no password.
If the ''password'' field is empty, the user automatically authenticates even with no password.
-
[[Essential CVS/Remote Repositories#cvs-CHP-8-EX-14|Example 8-14]] shows a ''passwd'' file.
+
[[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-14|Example 8-14]] shows a ''passwd'' file.
<div id="cvs-CHP-8-EX-14">
<div id="cvs-CHP-8-EX-14">
Line 521: Line 521:
* If a user is listed in both ''readers'' and ''writers'', CVS takes the conservative choice and she has read-only access to the repository.
* If a user is listed in both ''readers'' and ''writers'', CVS takes the conservative choice and she has read-only access to the repository.
-
Both files are one name per line. You must have a newline character after the last username. An example ''readers'' or ''writers'' file is shown in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-15|Example 8-15]].
+
Both files are one name per line. You must have a newline character after the last username. An example ''readers'' or ''writers'' file is shown in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-15|Example 8-15]].
<div id="cvs-CHP-8-EX-15">
<div id="cvs-CHP-8-EX-15">
Line 534: Line 534:
=== login and logout ===
=== login and logout ===
-
The ''passwd'' file controls whether the CVS server requires a password for any given user. If the server requires a password, ''pserver'' requires you to use the ''cvs login'' and ''cvs logout'' commands. Run the ''cvs login'' command before any other CVS command, setting the repository path, if necessary, with one of the usual methods. [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-16|Example 8-16]] shows how to log in with ''pserver'' mode.
+
The ''passwd'' file controls whether the CVS server requires a password for any given user. If the server requires a password, ''pserver'' requires you to use the ''cvs login'' and ''cvs logout'' commands. Run the ''cvs login'' command before any other CVS command, setting the repository path, if necessary, with one of the usual methods. [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-16|Example 8-16]] shows how to log in with ''pserver'' mode.
<div id="cvs-CHP-8-EX-16">
<div id="cvs-CHP-8-EX-16">
Line 544: Line 544:
</div>
</div>
-
You can also supply the password during the command, as shown in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-17|Example 8-17]].
+
You can also supply the password during the command, as shown in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-17|Example 8-17]].
<div id="cvs-CHP-8-EX-17">
<div id="cvs-CHP-8-EX-17">
Line 571: Line 571:
== Using inetd with gserver, kserver, and pserver ==
== Using inetd with gserver, kserver, and pserver ==
-
''gserver'' , ''kserver'' , and ''pserver'' access modes require a server to run on the repository computer. For these modes, the server is started with ''inetd'' or ''xinetd'' . ''inetd'' is configured in the "Other services" section of ''/etc/inetd.conf'', as shown in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-18|Example 8-18]] and [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-19|Example 8-19]]. Note that the configuration must be all on one line.
+
''gserver'' , ''kserver'' , and ''pserver'' access modes require a server to run on the repository computer. For these modes, the server is started with ''inetd'' or ''xinetd'' . ''inetd'' is configured in the "Other services" section of ''/etc/inetd.conf'', as shown in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-18|Example 8-18]] and [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-19|Example 8-19]]. Note that the configuration must be all on one line.
<div id="cvs-CHP-8-EX-18">
<div id="cvs-CHP-8-EX-18">
Line 601: Line 601:
</div>
</div>
-
If your version of ''inetd'' doesn't allow you to specify port numbers in ''inetd.conf'', add lines to ''/etc/services'', as shown in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-20|Example 8-20]]. Then use those service names instead of the port numbers in ''inetd.conf''.
+
If your version of ''inetd'' doesn't allow you to specify port numbers in ''inetd.conf'', add lines to ''/etc/services'', as shown in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-20|Example 8-20]]. Then use those service names instead of the port numbers in ''inetd.conf''.
<div id="cvs-CHP-8-EX-20">
<div id="cvs-CHP-8-EX-20">
Line 612: Line 612:
CVS looks for the ''cvs'' service if it is running ''kserver'' access mode, and it looks for ''cvspserver'' if it is running in ''gserver'' or ''pserver'' mode. If you installed CVS from a package, CVS may have been modified to use ''cvskserver''. Once''inetd.conf'' is set up, you'll need to restart ''inetd''.
CVS looks for the ''cvs'' service if it is running ''kserver'' access mode, and it looks for ''cvspserver'' if it is running in ''gserver'' or ''pserver'' mode. If you installed CVS from a package, CVS may have been modified to use ''cvskserver''. Once''inetd.conf'' is set up, you'll need to restart ''inetd''.
-
If you use ''xinetd'' instead of ''inetd'', you need to create ''/etc/xinetd.d/cvspserver'' or ''/etc/xinetd.d/cvskserver'' and enter code similar to the code shown in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-21|Example 8-21]], rather than editing''/etc/inetd.conf''.
+
If you use ''xinetd'' instead of ''inetd'', you need to create ''/etc/xinetd.d/cvspserver'' or ''/etc/xinetd.d/cvskserver'' and enter code similar to the code shown in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-21|Example 8-21]], rather than editing''/etc/inetd.conf''.
<div id="cvs-CHP-8-EX-21">
<div id="cvs-CHP-8-EX-21">
Line 630: Line 630:
</div>
</div>
-
The ''-f'', ''-T'', and ''--allow-root''options to the CVS server are the same as they are for ''inetd''. To use the code in [[Essential CVS/Remote Repositories#cvs-CHP-8-EX-21|Example 8-21]] for the ''kserver'' access method, change the filename and port and use ''kserver'' instead of ''pserver'' in the''server-args'' line. If ''cvspserver'' or ''cvskserver'' are defined in ''/etc/services'', the line that defines the port is not needed.
+
The ''-f'', ''-T'', and ''--allow-root''options to the CVS server are the same as they are for ''inetd''. To use the code in [[Essential CVS/CVS Administration/Remote Repositories#cvs-CHP-8-EX-21|Example 8-21]] for the ''kserver'' access method, change the filename and port and use ''kserver'' instead of ''pserver'' in the''server-args'' line. If ''cvspserver'' or ''cvskserver'' are defined in ''/etc/services'', the line that defines the port is not needed.
=== Client Ports ===
=== Client Ports ===

Revision as of 11:47, 7 March 2008

Essential CVS

Most projects involve a repository on a different machine than the client. This chapter discusses remote repositories, access methods, how to set up each access method, and security considerations for each type of access.

This chapter also discusses the two access methods for local repositories: local and fork. fork represents a way to access a local repository as if it were a remote repository.

CVS can operate equally well as a single program that handles both the sandbox and the repository or as a pair of programs — a client managing the sandbox and a server managing the repository.

CVS can run as a single program if both sandbox and repository are on the same computer or if the repository is on a file server and the computer the sandbox is on perceives the shared directories as local.

Warning

If your file server or networking filesystem caches directory listings, the cached listings invalidate CVS file locking. Do not use caching filesystems with CVS.

If your file server or networking filesystem changes files in transit, the changes can corrupt the CVS data. This corruption can be subtle enough that it doesn't show up for weeks or months.

If you have a personal repository for private work, you may choose to keep the repository on the same computer as your sandbox. If you are sharing a mainframe with several other people, you may have a shared repository on the same mainframe as your sandboxes. In such situations, be particularly careful to back up the repository. When the repository and the sandbox are on different computers, each acts as a partial backup of the other. When they are on the same computer, that inherent backup is not available.

Contents

Specifying Repository Paths

Whenever CVS runs a command from a client, it needs to know where to find the CVS repository. The address of the repository is called the repository path . CVS looks for repository paths in the sandbox, the CVSROOTenvironment variable, and the -d repository_path command option.

If you run a CVS command from within a sandbox, CVS uses the repository path that is stored in the sandbox. When a sandbox is not available — such as when you're creating a sandbox or issuing a command from outside a sandbox — you must specify which repository you are attempting to access. You also need to specify the repository path if you are in a sandbox but wish to access a different repository than the one the sandbox uses.

You can specify a repository path from the command line with the -d repository_pathoption, or you can specify it with the CVSROOT environment variable. CVS uses the path given with the -d option in preference to the path in the sandbox, and it uses either the sandbox or the -dpath in preference to the path in the environment variable.

Tip

The rtag, rlog, rdiff, rannotate, and export commands can run without a sandbox. If these commands are run outside a sandbox, they need either the -d option or the CVSROOT environment variable.

The format for a repository path is:

[:method:][[[user][:password]@]hostname[:[port]]]/path
            

The method can be one of the following:

local
For the local machine.
ext
For externally defined rsh or rsh-like connection methods (such as SSH).
fork
For connecting to a local machine as if it were a remote machine (useful if you are trying to diagnose problems).
server
For the internal rsh server, available only on some operating systems (including Windows).
gserver
For connections through the GSS-API (currently Kerberos 5.0).
kserver
For connections through Kerberos 4 and earlier.
pserver
For the pserver (built-in password server) connection method.

Everything except the path itself can be left out of a repository path definition.

If the method is left out, and the host is not included or is the local host, CVS uses the local access method. If the method is left out but the host is included, CVS uses either the server or the ext methods, depending on whether an internal rsh server is available. If user is left out, CVS uses the username in the current environment. If password is left out and required, CVS asks for it. If the port is left out and the method requires a port, CVS uses the default port for that method. (The default port for each access method is given in the following sections on each method.) If the host is left out, localhost is assumed.

Tip

If you put a colon immediately after the username, CVS attempts to connect with an empty password.

If an element of the repository path is included but not needed for the current method, CVS displays a message stating which element is not necessary.

The local Access Method

If your repository is on the same computer as your sandbox (or the sandbox you want to make) or on a shared filesystem that is accessed as if it were a local partition, you can use the localmethod to access the repository.

For the local access method, the repository path format is:

[:local:]/path
            

When running a command that requires an explicit path declaration, put the repository path in your CVSROOT environment variable or use the path as the argument to the -d repository_pathoption. You will most likely need this path declaration when creating a sandbox, but it is also necessary for cvs exportand cvs rtag.

Tip

If you just enter the directory path with no hostname or method declaration, CVS uses the local access method.

With local access, CVS does not run in client/server mode. One program manages both the sandbox and the repository. The program runs under the username that it was called with, and it has the access permissions of that user. Any programs CVS calls (such as programs called from a scripting file) run with the same username and access permissions.

If local access mode is being used on a single-user computer, security normally is not an issue. On shared filesystems or mainframes, your repository security problems are the same as the usual security issues for file sharing. Use the security services of your operating system to secure a shared repository that is accessed with the local method.

Example 8-1 shows how to check out a sandbox using the local access method.

Example 8-1. Using the local access method

jenn@helit:/tmp$ cvs -d :local:/var/lib/cvs checkout wizzard
cvs checkout: Updating wizzard
U wizzard/Changelog
U wizzard/INSTALL
U wizzard/Makefile

The ext and server Access Methods

In my experience, ext is the most commonly used access method, and it is usually used with SSH. ext stands for external, which refers to an external (to CVS) rsh or remote shell program. This method uses a remote shell program to connect the sandbox client computer to the repository server computer. The server method is almost the same as the ext method. The only difference is that server uses a remote shell program that is included with CVS.

To use a program other than rsh with the ext connection method, the CVS_RSH environment variable on the client should be set to the name of the program and the directory containing the program should be in the user's PATH on the client computer. Alternatively, you can set the CVS_RSH environment variable to the absolute path to the program, without modifying the PATH variable.

ext accepts any command line-based program that can be called with the following syntax:

program [-b] [-l username] host commands

The program must run the commands in a remote shell and pipe standard input (stdin) and standard output (stdout) without filtering the content. The -b is necessary only if the program is running on OS/2 and is used to force rsh to run in binary mode, without end-of-file conversion. The-l username is used (by CVS) only if there is a username included in the repository path.

For the ext access method, the repository path format is:

[:ext:][user@]hostname[:]/path
            

The user needs to have a username on both the client computer and the server computer. If these names are the same, the user@ part of the repository path isn't needed. In versions of CVS prior to 1.11.1, the colon between hostname and path was required.

Either the user's PATH environment variable on the server must include the directory that contains the cvs executable, or the user's CVS_SERVER environment variable on the client must contain the path to the cvs executable on the server. If you're using PATH, this variable must be set in a configuration file, such as .cshrc or .bashrc, that is read by nonlogin shells.

The rsh (or rsh-like) program starts the cvs executable on the server computer, using the username and permissions of the user the rsh program has connected as. Any programs CVS calls (such as programs called from a scripting file) run with this username and access.

As a trouble-prevention measure, before trying to use your rsh or rsh-like program with CVS, attempt to log into the server with it, using the program [-b] [-l username] host commandscommand format, as shown in Example 8-2.

Example 8-2. Testing SSH for ext

bash-2.05a$ ssh -l jenn helit ls
jenn@helit's password: 
Mail
MyMozilla
MyPilot
...

Neither the rsh nor the server methods use encryption, and both transmit a clear-text username and password to a valid user account on the repository server. For this reason, I strongly recommend you use SSH or some other secured connection whenever you connect across an untrusted network. You should consider using a secured connection even on a trusted network. If there is any external connection to your network (even through a firewall), I recommend encrypting the connection.

Example 8-3 shows how to check out a sandbox using the ext access method.

Example 8-3. Using the ext access method

bash-2.05a$ cvs -d :ext:jenn@cvs:/var/lib/cvs checkout wizzard
cvs server: Updating wizzard
U wizzard/Changelog
U wizzard/INSTALL
U wizzard/Makefile

rsh

rsh is the default program used with the ext method. If no other program is specified in the CVS_RSH environment variable, CVS calls rsh. If rsh is not in the user's PATH on the client or not available on the server, CVS cannot connect.

On the server, the user's .rhosts file in the user's home directory must have a line in the format client_name username, where client_name is the name of the client computer and username is the user's name on the client computer.

Tip

The rsh program provided with Windows NT modifies end-of-line characters and is unsuitable for use with CVS. In the HP-UX 9 operating system, use the remsh program rather than rsh, as rsh is a different program entirely. Use the CVS_RSH environment variable to define the replacement programs for both operating systems.

The server Access Method

The server access method uses a version of rsh internal to CVS. The.rhosts file on the server must be set, as described in Section 8.3.1 of this chapter.

To determine whether the server access method is available you can attempt to check out a sandbox with the method, as shown in Example 8-4.

Example 8-4. Testing for server mode

bash-2.05a$ cvs -d :server:cvs:/var/lib/cvs checkout wizzard
cvs [checkout aborted]: the :server: access method is not supported by this port of CVS

The server method is not available in all operating systems. Both client and server must be able to run the internal rsh program.

SSH

Secure Shell (SSH) is an rsh replacement that encrypts the data stream. You can authenticate your SSH connection with a pair of keys (private and public) or with a password.

There are two SSH protocols: SSH1 and SSH2. The server must be running an SSH daemon that understands the protocol the client is using. SSH clients also come with a key-generation program that generates the private and public keys that will be used to encrypt the data stream.

To use SSH with CVS:

  1. Install an SSH client on the sandbox computer and a daemon on the repository server, as given in the instructions for your SSH programs. Ensure that the path to the SSH program is in the PATH environment variable on the client computer.
  2. Ensure that the server speaks the same protocol as the client. If the documentation for either program doesn't specify whether it uses SSH1 or SSH2, it probably uses the older, SSH1 protocol.
  3. Ensure that the user has a username and password for the server as well as the client.
  4. Generate an SSH key for the client, using the key-generation program. You may add the key to the user's home directory on the server, as explained in the documentation for your SSH program. If you do so, the user won't need to provide a password when connecting with SSH. This step is optional.
  5. Test whether the connection works by attempting to log in to the server with the username from step 3, as shown in Example 8-5.
  6. Put the name of your SSH program (or its path) into the CVS_RSH environment variable on the client computer.
  7. Run CVS usingext as the method in the repository path, as shown in Example 8-3.

Example 8-5 shows a test connection to a server with an SSH client program, as described in step 5.

Example 8-5. Connecting with SSH

bash-2.05a$ ssh -l jenn helit
Linux helit 2.4.19-686-smp #1 SMP Thu Aug 8 22:06:13 EST 2002 i686 unknown unknown GNU/
Linux
.
.
.
Last login: Tue Oct 15 17:43:40 2002 from 10.0.2.2
jenn@helit:~$

I recommend http://www.openssh.org/ and the FAQ file at http://www.openssh.org/faq.html as sources of information on SSH. This site also provides free SSH client and server programs.

Other Connection Programs

The ext method can run with any other program that calls a remote program in the way that rsh and ssh do. The program must not modify data in transit, and it must be called using the format:

                  program [-b] [-l username] host commands
               

If you wish to use Kerberos with CVS, you can use the Kerberos version of rsh to connect using the ext method. If you wish to use Kerberos more directly, use the kserver or gserver access methods.

If you need to call rsh or ssh with an option, write a shell script like the one in Example 8-6 and put the path to that shell script in yourCVS_RSH variable. CVS will invoke the shell script, which in turn will invoke rsh or ssh with the options you desire.

Example 8-6. Invoking ssh with command-line options

#! /bin/bash
exec ssh -F ~/.sshconf "$@"

The fork Access Method

Thefork access method acts likeext without the external connection. You can use it only when the repository and the sandbox are on the same computer. fork makes CVS run in client/server mode and is most useful for debugging — to isolate whether a fault is in CVS's remote protocols or in the networking — but it is also used as a substitute for the local method.

The fork method uses the CVS_SERVER environment variable, as described in Section 8.3 earlier in this chapter.

The repository path format for fork is:

[:fork:]/path
            

With the fork access method, both client and server programs run under the username that the client was called with and have the filesystem access of that user. Any programs CVS calls (such as programs called from a scripting file) run with the same username and access.

Security normally is not an issue with the fork access method if the method is used on a single-user computer. However, be aware of the security issues of shared filesystems or shared mainframes; use the security services of your operating system to secure a shared repository that is accessed with the fork method.

Example 8-7 shows how to check out a sandbox using the fork access method.

Example 8-7. Using the fork access method

jenn@helit:/tmp$ cvs -d :fork:/var/lib/cvs checkout wizzard  
cvs server: Updating wizzard
U wizzard/Changelog
U wizzard/INSTALL
U wizzard/Makefile

The gserver Access Method

The gserver access method uses the GSS-API (Generic Security Service Application Programming Interface) to support authentication and encryption of the CVS connection. The GSS-API in itself does not authenticate or encrypt the connection; these processes are performed by an authentication or encryption system configured to work with the GSS-API. The most common system used with the GSS-API is Kerberos 5.

The GSS-API is explained in RFC 2743, available at http://www.ietf.org/rfc/rfc2743.txt. RFC 1964 explains how the GSS-API interacts with Kerberos 5. To use Kerberos 5 with CVS, use the GSS-API and the gserver access method. Kerberos 4 is used with the kserver access mode, explained in the next section.

The repository path format for the GSS-API is:

:gserver:[user@]hostname[:[port]]/path
            

The default port for gserver is 2401. If user is not specified, the client sends the username of the calling user on the client computer.

The CVS client and server must both be compiled to run the GSS-API. If you intend to encrypt the data stream, you also need to have encryption enabled at compile time. You can test whether your CVS program has the GSS-API compiled by attempting to check out a sandbox. Example 8-8 shows the result when CVS does not support the GSS-API.

Example 8-8. Testing for gserver mode

bash-2.05a$ cvs -d :gserver:cvs:/var/lib/cvs checkout wizzard
cvs checkout: CVSROOT is set for a GSS-API access method but your
cvs checkout: CVS executable doesn't support it.
cvs [checkout aborted]: Bad CVSROOT: `:gserver:cvs:/var/lib/cvs'.

You can test for encryption support by checking the options list, as shown in Example 8-9.

Example 8-9. Checking for encryption

bash-2.05a$ cvs --help-options 
CVS global options (specified before the command name) are:
.
.
.
    -x           Encrypt all net traffic.
.
.
.
(Specify the --help option for a list of other help options)

To recompile CVS to support the GSS-API, follow the instructions given below. A more detailed discussion on installing from source is provided in Chapter 2, but the examples in that discussion do not include the GSS-API.

You need to use the --with-gssapi[=directory]option to configure CVS to use the GSS-API. If you want encryption, use --enable-encryptas well.

Note

Check your INSTALL file for the exact syntax of configuration options in your version of CVS.

On some operating systems, the GSS-API is installed automatically. If that's the case with your system, you may need to use --without-gssapi if you don't also have Kerberos 5 available.

To compile CVS with GSS-API support:

  1. Ensure that your computer has an installation of both the GSS-API and Kerberos 5, with the header files.
  2. cd to the CVS source directory.
  3. Run make distclean to remove any cached configuration information or other remnants of previous compilations.
  4. Run configure with the arguments you need. To configure CVS for the GSS-API, you need --with-gssapi [ =header files]. To enable encryption, use --enable-encrypt. The header files argument to --with-gssapi should be the path of the GSS_APIdirectory that contains libraries and include files (or a directory above that directory).
  5. Run make.
  6. Change user to root or another privileged user.
  7. Run make install.

Tip

Check the output of configure carefully to ensure that CVS read the GSS-API include files. The output from configure is saved in config.log.

Using the GSS-API, CVS can authenticate and encrypt the data stream, but it does not do these things by default. Use the -a CVS option to authenticate the data stream, and use the -xCVS option to encrypt it. You may want to include these options in your .cvsrc file. For example, to both authenticate and encrypt the data stream, place the following in .cvsrc:

cvs -ax

To support the gserver access method, CVS needs to run a server on the computer that hosts the repository. CVS uses most of the same code to support the gserver and pserver methods. To configure the repository to run the CVS server, edit inetd.conf and add cvs pserver (not gserver). See Section 8.8 of this chapter for more information on this configuration.

Install and configure Kerberos 5, per the instructions for your Kerberos system. The principal name for CVS is cvs/HOSTNAME, where HOSTNAME is the canonical name of the host.

Warning

CVS 1.11.2 has a bug in its GSS-API code. It fails to connect and produces the following error message whenever it attempts to connect to a GSS-API server: cvs [import aborted]: gserver currently only enabled for socket connections.

Later versions do not have this problem, and there is a patch for 1.11.2 in the archives of the info-cvs mailing list.

The extent to which the GSS-API is secure depends on the particular system you choose and whether you choose to authenticate or encrypt the message stream. It's useful because of that flexibility; you can determine precisely which level of security you want. At present, the only system available to work with the GSS-API and CVS is Kerberos 5, which provides a high level of authentication security across an untrusted network, if the hosts connecting through it are secure.

Once the GSS-API and Kerberos 5 are installed and configured and CVS is recompiled, you can get a Kerberos ticket for your user on the client and then run CVS commands normally. Example 8-10 shows how to check out a sandbox using the gserver access method.

Example 8-10. Using the gserver access method

bash$ cvs -d :gserver:helit:/var/lib/cvs checkout wizzard
cvs server: Updating wizzard
U wizzard/Changelog
U wizzard/INSTALL
U wizzard/Makefile

The kserver Access Method

The kserver method is used to connect using Kerberos 4. If you do not have an existing Kerberos 4 installation on your CVS repository server, I recommend you use Kerberos 5. Kerberos 4 has known weaknesses that Kerberos 5 resolves. This section assumes that you have an existing Kerberos 4 installation and the documentation to configure and use it.

Tip

Kerberos 4 is a reasonably secure authentication system, but it has known flaws. Kerberos 5 fixes some of them; most critically, it prevents a replay attack. In Kerberos 4, there is a five-minute window in which an attacker can sniff an authentication request, modify and re-send it, and get an authentication ticket. Kerberos 5 allows only one ticket to be produced per request.

The repository path format for Kerberos is:

:kserver:[user@]hostname[:[port]]/path
            

The default port for kserver is 1999. If user is not specified, the client sends the username of the calling user on the client computer.

The CVS client and server must both be compiled to run Kerberos 4. If you intend to encrypt the data stream, you also need to have encryption enabled at compile time. You can test whether your CVS program has compiled kserver support by checking the command list, as shown in Example 8-11.

Example 8-11. Testing for kserver mode

bash-2.05a$ cvs --help-commands
CVS commands are:
.
.
.
        kserver      Kerberos server mode
.
.
.
(Specify the --help option for a list of other help options)

You can test for encryption support by checking the options list, as shown earlier in Example 8-9.

To use CVS with kserver, install and configure Kerberos 4 as described in your Kerberos manual. You need to have the header files for Kerberos 4 available for CVS to link to. The principal name for CVS is cvs.

To recompile CVS to support Kerberos 4, follow the instructions in Chapter 2 on installing from source. Use the --with-krb4[=header-files]option to configure to get Kerberos authentication support. Use the Kerberos directory as the argument to--with-krb4. (You need the Kerberos directory you intend to compile against, usually one with include and lib subdirectories.) If you also desire encryption, use --enable-encryptas well.

Tip

Check your INSTALL file for the exact syntax of configure options in your version of CVS.

CVS needs to run a server on the repository computer to support the kserver access method. Edit inetd.conf and add a line for cvs kserver. See Section 8.8 of this chapter for details on how to edit inetd.conf.

Using Kerberos 4, CVS can encrypt the data stream, but it does not do this by default. Use the -xoption to encrypt the data stream. You may want to include this option in your .cvsrc file. For example:

cvs -x

To run CVS, get a Kerberos ticket for the user on your client; then call CVS the usual way with the kserver method. Example 8-12 shows how to check out a sandbox using the kserver access method.

Example 8-12. Using the kserver access method

bash$ cvs -d :kserver:helit:/var/lib/cvs checkout wizzard
cvs server: Updating wizzard
U wizzard/Changelog
U wizzard/INSTALL
U wizzard/Makefile

The pserver Access Method

The pserver method allows users to connect to the repository with a username and password that are stored on the repository server. The main advantage of pserver is that it permits anonymous, passwordless, read-only access. The main disadvantages of pserver mode are that it uses a trivial encoding scheme for passwords and the data stream is not encrypted. pserver mode is included in CVS automatically, but it requires a password file that needs to be configured.

To use pserver, you need a username on the repository computer, to enable CVS to run programs on that computer. You may share this username (your system username) with other users and have a separate CVS username to identify you to CVS as an individual. You also need to log in before running other commands.

To support the pserver access method, CVS needs to run a server on the computer that hosts the repository. To configure the repository to run the CVS server, edit inetd.conf and add cvs pserver. See Section 8.8 of this chapter for more information on inetd configuration.

The repository path format for pserver is:

:pserver:[[user][:password]@][hostname:[port]]/path
            

The default port for pserver is 2401. If the user is not specified, the client sends the username of the calling user on the client computer.

You need to configure the passwd file and possibly the readers and writers files before you can use pserver. These files are explained in Section 8.7.1 and Section 8.7.2 of this chapter. You also need to use the login command, explained in Section 8.7.3 .

Warning

You can bypass the passwd file by using the SystemAuth configuration option in the config file (explained in Chapter 6).

If you bypass the passwd file using SystemAuth, CVS uses the shell account passwords for your users with the minimal security it uses for pserver passwords. Be sure you take the security risks into account if you choose to do this.

Once CVS is configured for pserver, you can check out a sandbox or use other CVS commands normally, using the pserver repository path when necessary. Example 8-13 shows how to check out a sandbox using the pserver access method.

Example 8-13. Using the pserver access method

bash-2.05a$ cvs -d :pserver:jenn@cvs:/var/lib/cvs login
Logging in to :pserver:jenn@cvs:2401/var/lib/cvs
CVS password:
bash-2.05a$ cvs -d :pserver:jenn@cvs:/var/lib/cvs checkout wizzard
cvs server: Updating wizzard
U wizzard/Changelog
U wizzard/INSTALL
.
.
.

The passwd File

The passwd file in the repository's CVSROOT directory stores passwords and usernames for the pserver access method. The format is as follows:


                  CVS_username:password:system_username
               

The CVS_username is the name the user sends to CVS. The system_username is the name the CVS programs run under. If these names are the same, the system_username does not need to be given, as it defaults to the CVS_username. The CVS_username is shown in the author field of cvs log output.

The system_username must exist on the repository server. The CVS_username doesn't need to exist on the server unless it's the same as the system_username. If the system_username does not exist on the server, the commands fail, even if the user authenticates as far as CVS is concerned.

If the password field is empty, the user automatically authenticates even with no password.

Example 8-14 shows a passwd file.

Example 8-14. A passwd file

anonymous:
jenn:ENCRYPTEDPASSWORD
doppel:ENCRYPTEDPASSWORD
chris:ENCRYPTEDPASSWORD:cvsusers
peter:ENCRYPTEDPASSWORD:cvsusers
asmith:ENCRYPTEDPASSWORD:anne

The passwords are encrypted with the standard Unix crypt( ) function and need to be encrypted elsewhere and pasted in; there currently is no code that edits this file. You can use the Unix mkpasswd utility to create a suitable encrypted string from a plain-text password.

Tip

Another way to generate passwords is to use the Perl command perl -e 'print crypt "password", "salt";'. Replace salt with any two characters, to randomize the results.

A single system username can be shared by multiple users with different CVS'usernames. This can be used to allow several people to work on a project and record the changes across multiple users. (Of course, this could also be done with group permissions.) If appropriate for your security needs, you can restrict the system usernames so that they can only run CVS.

The passwd file should be edited in place; it should not be checked out to sandboxes.

Note

You can grant anonymous, read-only access to CVS using pserver. Set up the passwd file in the CVSROOT directory with the user anonymous (or any other username) with no password or system name, and add the user anonymous to the readers file.

A better way to grant anonymous, read-only access is to use the operating system's built-in security. This method is explained in Chapter 6.

The readers file is described in the next section.

The readers and writers Files

The readers and writers files in the repository's CVSROOT directory control whether someone using the pserver access method has permission to write to the repository. These files affect only users using the pserver access method; repository access using the other access methods is controlled by the filesystem permissions.

The readers and writers files use the CVS username, not the system username, to determine whether a user has access.

Users gain access to the repository according to the following rules:

  • If a user is listed in the readers file, she has read-only access to the repository.
  • If the writers file exists and a user is not listed in the writers file, she has read-only access to the repository.
  • If a user is listed in the writers file but not in the readers file, she has read-write access to the repository.
  • If a user is listed in both readers and writers, CVS takes the conservative choice and she has read-only access to the repository.

Both files are one name per line. You must have a newline character after the last username. An example readers or writers file is shown in Example 8-15.

Example 8-15. readers or writers file

jenn
doppel
asmith
peter

login and logout

The passwd file controls whether the CVS server requires a password for any given user. If the server requires a password, pserver requires you to use the cvs login and cvs logout commands. Run the cvs login command before any other CVS command, setting the repository path, if necessary, with one of the usual methods. Example 8-16 shows how to log in with pserver mode.

Example 8-16. Logging in with pserver

bash-2.05a$ cvs -d :pserver:jenn@cvs.nosuch.net:/var/lib/cvs login
Logging in to :pserver:jenn@cvs:2401/var/lib/cvs
CVS password:

You can also supply the password during the command, as shown in Example 8-17.

Example 8-17. Giving a password at login

bash-2.05a$ cvs -d :pserver:jenn:password:@cvs.nosuch.net:/var/lib/cvs login
Logging in to :pserver:jenn@cvs:2401/var/lib/cvs

Once you have successfully logged in, CVS records the password and other data in the.cvspass file in your home directory on your client computer. This filename can be changed by putting the path to the new file in the CVS_PASSFILE environment variable in the client before you run login. CVS stores the data indefinitely in the format /1 user@host:port/path Aencoded_password, one repository to a line. (Yes, there is a literal A before the password; that's an internal version identification system.)

You can remove this line from the file by using cvs logoutwith the same CVSROOT, in which case you would need to log in again the next time you wish to use pserver access to connect to that repository.

The password is encoded using a simple encoding scheme and can be decrypted easily by a malicious user. It is encoded against inadvertent, nonmalicious reading, but it is not secure.

Security

CVS searches the passwd file in the CVSROOT directory for usernames and passwords for pserver access. Because of the trivial encoding, passwords used for pserver access should not be the same as the passwords used for access to the main filesystem of the repository server. The passwdfile should not be included in the checkoutlist list in the cbeckoutlist file. It should always be edited in place, because multiple copies of the passwords in various sandboxes is a security risk.

CVS can also fall back to system-level user authentication. If a user is not found in the passwd file, CVS (by default) authenticates the user with the system's normal authentication method. To prevent users from connecting to CVS with systemwide passwords, this fallback system should usually be disabled; it should definitely be disabled if the data might be transmitted across an untrusted network. Disable it by editing the config file in the CVSROOT directory and setting the SystemAuth value to no.

If users with pserver access can edit the CVSROOT scripting files, an attacker who decrypts a pserver access password can force CVS to run arbitrary scripts. Fortunately, scripts run with the access level of the system user as determined when CVS reads the passwd file; the access level is not determined by the daemon that runs CVS.

Be aware that once an intruder has write access to the CVS repository, he may be able to gain additional access to the system. If your communications travel over a hostile network, don't use pserver for access where users can change data. pserver can be useful for read-only, anonymous access, but I recommend you use something else for other kinds of access. If you need to use pserver, an SSH tunnel may be a reasonable compromise.

Using inetd with gserver, kserver, and pserver

gserver , kserver , and pserver access modes require a server to run on the repository computer. For these modes, the server is started with inetd or xinetd . inetd is configured in the "Other services" section of /etc/inetd.conf, as shown in Example 8-18 and Example 8-19. Note that the configuration must be all on one line.

Example 8-18. Inetd for gserver and pserver

#:OTHER: Other services
2401 stream tcp nowait root /usr/bin/cvs cvs -f --allow-root=/var/lib/cvs pserver

Example 8-19. Inetd for kserver

#:OTHER: Other services
1999 stream tcp nowait root /usr/bin/cvs cvs -f --allow-root=/var/lib/cvsroot kserver

The gserver access method connects to a pserver CVS server. The code that runs the server end of pserver checks whether it has been connected to with the pserver or gserver access method and runs the appropriate server code.

The parameter to the --allow-root option is the path to the repository root directory. If there will be several different repository root directories, add more --allow-rootoptions.

You can use the -T option or the TMPDIR environment variable to set a specific temporary directory. If no directory is listed, /tmpis used.

Note

It can be useful to run the server as a special user, possibly named cvs, to limit the amount of damage that can be done if one of the arbitrary scripts (or CVS itself) is insecure. If you do this, ensure that the repository root directory and the CVSROOT files start out being owned by the cvs user, and make sure that the cvs user is in all the groups that can use the repository. You also need to ensure that all users run as user cvs, perhaps by having that as the system username in pserver access mode.

If CVS has root privileges, it runs the scripts called from the scripting files as the user who calls CVS, not the user named in inetd, so this is not a special concern.

If your version of inetd doesn't allow you to specify port numbers in inetd.conf, add lines to /etc/services, as shown in Example 8-20. Then use those service names instead of the port numbers in inetd.conf.

Example 8-20. Port services

cvspserver 2401/tcp
cvs 1999/tcp   cvskserver

CVS looks for the cvs service if it is running kserver access mode, and it looks for cvspserver if it is running in gserver or pserver mode. If you installed CVS from a package, CVS may have been modified to use cvskserver. Onceinetd.conf is set up, you'll need to restart inetd.

If you use xinetd instead of inetd, you need to create /etc/xinetd.d/cvspserver or /etc/xinetd.d/cvskserver and enter code similar to the code shown in Example 8-21, rather than editing/etc/inetd.conf.

Example 8-21. xinetd

service cvspserver
{
    port = 2401
    socket_type = stream
    protocol = tcp
    wait = no
    user = root
    passenv = PATH
    server = /usr/bin/cvs
    server-args = -f --allow-root=/var/lib/cvs pserver
}

The -f, -T, and --allow-rootoptions to the CVS server are the same as they are for inetd. To use the code in Example 8-21 for the kserver access method, change the filename and port and use kserver instead of pserver in theserver-args line. If cvspserver or cvskserver are defined in /etc/services, the line that defines the port is not needed.

Client Ports

If you're using pserver or gserver, the client defaults to use port 2401. If your repository server is listening on a different port, specify the port in the repository path or set the CVS_CLIENT_PORT environment variable on the client computer. You can also compile the client with the CVS_AUTH_PORT macro set to the new port.

If you're using kserver , the client defaults to use port 1999. If your repository server is listening on a different port, you can use the repository path or the CVS_CLIENT_PORT environment variable. The CVS_PORT macro sets the default port for kserver mode during compilation.

Personal tools