15.4.1.1 USERFILE entries

USERFILE is one of the more complicated parts of Version 2 UUCP . In some cases, making a mistake with USERFILE can prevent UUCP from working at all. In other cases, it can result in a security hole.

Entries in USERFILE take the form:

username,system-name [c] pathname(s)

An entry in USERFILE that uses all four fields might look like this:

Ugarp,garp c /usr/spool/uucppublic

These fields are described in Table 15.2 .

Table 15.2: USERFILE Fields

Field	Example	Function in USERFILE
username	Ugarp	Login name in /etc/passwd that will be used
system name	garp	System name of the remote system.
c	c	Optional callback flag. If present, uucico on the local computer halts conversation after the remote machine calls the local machine; uucico on the local machine then calls back the remote machine to establish the remote machine's identity
pathname	/usr/spool/uucppublic	List of absolute pathname prefixes separated by blanks. The remote system can access only those files beginning with these pathnames. A blank field indicates open access to any file in the system, as does a pathname of /.

You should have at least one entry in USERFILE without a username field, and at least one other entry without a system name field:

• The line that has no username field is used by uucico when it is transmitting files, to determine if it is allowed to transmit the file that you have asked to transmit.

• The line that has no system name field is used by uucico when it is receiving files and cannot find a name in the USERFILE that has a system name matching the current system. uucico uses this line to see if it is allowed to place a file in the requested directory. This line is also used by the uuxqt program.

To make things more interesting, almost every implementation of UUCP parses USERFILE a little differently. The key rules that apply to all versions are:

• When uucp and uux are run by users, and when uucico runs in the Master role (a connection originating from your local machine), UUCP uses only the username part of the username and system name fields.

• When uucico runs in the Slave role, UUCP looks only at the system name field.

• There must be at least one line that has an empty system name, and one line that has an empty username. (In most BSD -derived systems, they can be the same line. Every other implementation requires two separate lines. You are safest in using two lines if you don't understand what your version allows.) The locations of these lines in the file is not important, but both lines must be present.

15.4.1.2 USERFILE entries for local users

You can have an entry in your USERFILE for every user who will be allowed to transfer files. For example, the following entries give the local users lance and annalisa permission to transfer a file in or out of any directory on your computer to which they have access:

lance, /
annalisa, /

This USERFILE entry gives the local user casper permission to transfer files in or out of the UUCP public directory or the directory /usr/ghost :

casper, /usr/spool/uucppublic /usr/ghost

Be aware that USERFILE allows a maximum of 20 entries in Version 7 and System V Release 1.0.

Instead of specifying a USERFILE entry for each user on your system, you can specify a USERFILE entry without a username. This default entry covers all users on your system that are not otherwise specified. To give all users access to the UUCP public directory, you might use the following USERFILE entry:

,localhost /usr/spool/uucppublic

(The hostname localhost is ignored by the UUCP software and is included only for clarity.)

15.4.1.3 Format of USERFILE entry without system name

To allow file transfer from other systems to your system, and to allow files to be accessed by uuxqt (even when it is started from your system), you must have at least one entry in USERFILE for which the system name is not specified. For example:

nuucp, /usr/spool/uucppublic

Although you might expect that this line would mean that any system logging in with the name nuucp would have access to /usr/spool/uucppublic , such is not the case for all versions of UUCP .

In System V Release 2.0 and in Ultrix, UUCP will actually check both the username field and the blank system name field, and will allow logins by any system using nuucp .

In other UUCP implementations, however, the fact that nuucp appears on this line is completely irrelevant to a system calling in. The system name is used only to validate file transfers for files that are received by your system. If this is the first entry with a missing system name, UUCP will actually allow access to uucppublic by any system for which there is no explicit USERFILE entry containing that system's system name. If this is not the first entry with a blank system name, it will have no effect.

15.4.1.4 Special permissions

You may wish to make special directories on your system available to particular users on your system or to particular systems with which you communicate. For example:

Ugarp,garp /usr/spool/uucppublic /usr/spool/news

This line will make both the directories /usr/spool/uucppublic and /usr/spool/news available to the system name garp when you call it, and to any system that logs in with the UUCP login Ugarp . You might want to add this line if you anticipate transferring news articles between your computer and garp directly, without going through the Usenet news software.

15.4.1.5 Requiring callback

Version 2 UUCP has a callback feature that you can use if you are extremely concerned about security. With callback, when a remote system calls your computer, your system immediately hangs up on the remote system and calls it back. In this way, you can be sure that the remote system is who it claims to be.

If you put a c as the first entry in the USERFILE path list, no files will be transferred when the remote system's uucico logs in. Instead, your system will call back the remote system. No special callback hardware is required to take advantage of UUCP callback, because it is performed by the system software, not by the modem.

For example, here is garp's USERFILE entry modified so the local system will always call garp back whenever garp calls the local system:

Ugarp,garp c /usr/spool/uucppublic /usr/spool/news

Callback adds to the security of UUCP . Normally there is no way to be sure that a computer calling up and claiming to be garp , for example, is really garp . It might be another system that belongs to a computer cracker who has learned garp 's UUCP login and password. If you call back the remote system, however, you can be reasonably sure that you are connecting to the right system.

NOTE: Only one system out of each pair of communicating systems can have a c in its USERFILE to enable the callback feature. If both ends of a connection enable callback, they will loop endlessly - calling each other, hanging up, and calling back. For more information, see the comments on callback in Chapter 14, Telephone Security .

15.4.2.1 Some bad examples

If you are not very concerned about security, the following USERFILE might suffice:

# A wide open USERFILE
nuucp, /usr/spool/uucppublic
, /

However, we recommend against it! This USERFILE will allow remote systems (assuming that they all log in as nuucp ) to transfer files to or from the public directory, but will give complete UUCP access to local users. This is dangerous and is not recommended, as it allows local users access to any protected file and directory that is owned by uucp .

If you don't talk to the outside world and are using UUCP only for communication with UNIX sites inside your organization, you might use the following USERFILE :

# A completely open USERFILE
, /
, /

This userfile will allow any user on your system, or any remote system, to transfer files to or from any directory. This example is even more dangerous than the previous one. (Note that on many systems, two lines are necessary, even though they are identical. The first line defines the missing username, and the other line defines the missing system name. In some systems, a single line will suffice, but you will never be wrong if you include both of them.)

Remember that even with complete access specified in USERFILE , UUCP is still subject to UNIX file permissions. A user requesting outbound transfer of a file must have read access to it. For a remote system to have access to a file or directory, the file or directory must be readable and writable by all users, or by UUCP .

NOTE: If you wish to run a secure system, the directory /usr/lib/uucp (or /etc/uucp ) must not be in the permission list! If users from the outside are allowed to transfer into these directories, they can change the USERFILE or the L.cmds files to allow them to execute any command that they wish. Local users can similarly use the uucp command to change these files, and subvert UUCP . Giving all access from the / directory is also dangerous - such access makes it possible for people outside your organization to subvert your system easily, as they can then modify any directory on your system that is world writable.

For example, granting access to / lets an outsider read the contents of your /etc/passwd file, and also allows him to read and change the contents of your /usr/lib/uucp/L.sys file. As an added precaution, the home directory for the uucp user should not be in /usr/spool/uucp/uucppublic, or any other directory that can be written to by a uucp user. Doing so may allow an outside user to subvert your system.