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.
|
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.
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 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.
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.
|
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.
|
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.
jenn doppel asmith peter
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.
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.
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 logout with 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.
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 passwd file 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.
|
|
|
| Top |
