Version 2 of UUCP provides five files that control what type of access remote systems are allowed on your computer (see Table 15.1 ).
The two files of primary concern are USERFILE and L.cmds ; for a detailed description of the other files, please see the book Managing UUCP and Usenet referenced above.
The /usr/lib/uucp/USERFILE file controls which files on your computer can be accessed through the UUCP system. Normally, you specify one entry in USERFILE for each UUCP login in the /etc/passwd file. You can also include entries in USERFILE for particular users on your computer: this allows you to give individual users additional UUCP privileges.
USERFILE entries can specify four things:
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 .
You should have at least one entry in USERFILE without a username field, and at least one other entry without a system name field:
To make things more interesting, almost every implementation of UUCP parses USERFILE a little differently. The key rules that apply to all versions are:
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:
(The hostname localhost is ignored by the UUCP software and is included only for clarity.)
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:
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.
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.
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.
Here is a sample USERFILE :
, /usr/spool/uucppublic # Next line not needed in BSD 4.2 or 4.3 nuucp, /usr/spool/uucppublic dan, /usr/spool/uucppublic /u1/dan csd, /usr/spool/uucppublic /u1/csd root, / udecwrl,decwrl /usr/spool/uucppublic /usr/spool/news upyrnj,pyrnj /usr/spool/uucppublic /usr/src
As noted earlier, in some systems the first line defines both the missing username and the missing system name and gives access to the directory /usr/spool/uucppublic . In other implementations of UNIX , two separate lines are required: The first line will suffice for the missing username, and another line, such as the second one shown here (the line beginning with nuucp ), will account for the missing system name.
The effect of these lines is to allow any local user, and any remote machine, to transfer files only from the public directory.
If you don't have any particularly trusted sites or users, you may want to stop at this point. However, if you want to give special privileges to particular local users, you'll include lines such as the next three (the lines beginning with dan , csd , and root ). Users dan and csd can transfer files to or from their home directories as well as from the public directory. Users logged in as root can transfer files to or from any directory. (This structure makes sense, as they can do anything else, including modifying USERFILE to suit their needs or whims.)
Finally, you may need to specify particular permissions for known local systems. In the example, decwrl is able to transfer files to /usr/spool/news as well as to the public directory. The site pyrnj is able to transfer files to and from /usr/src as well as to and from the public directory.
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 .
You will probably want to limit the commands that can be executed by a remote system via uucp . After all, if any command could be executed by UUCP , then people on other computers could use the /bin/rm command to delete files in any writable directory on your computer! 
For this reason, UUCP allows you to specify which commands remote systems are allowed to execute on your computer. The list of valid commands is contained in the directory /usr/lib/uucp in the file L.cmds , L-cmds , or uuxqtcmds (different versions store the command list in different files). Some early UNIX systems (Version 7 or earlier) may not have this file at all (and have no way of changing the defaults without modifying the source code to the uuxqt program.) For further information, check your own system's documentation.
In some versions of UUCP , the L.cmds file can also include a PATH = statement that specifies which directories uuxqt should check when searching for the command to execute.
A typical L.cmds file might contain the following list of commands:
PATH=/bin:/usr/bin:/usr/ucb rmail rnews lpr who finger
If a command is not in the commands file, uux cannot execute it. L.cmds should at least contain the rmail program (the remote mail program that decides whether mail is to be delivered locally or forwarded on to yet another system). If rmail is not listed in L.cmds , a local user will not be able to receive mail from remote users via UUCP .
Add commands to this file carefully; commands like cat or rm may place your system at risk. You should be careful about commands that allow shell escapes (such as man ). Even finger can be dangerous if you are very concerned about security, because it might provide a cracker with a list of usernames to try when guessing passwords.
Look carefully at the L.cmds file that comes with your system: you may wish to remove some of the commands that it includes. For example, some BSD -derived systems include the ruusend command in this file, which allows file forwarding. This command is a security hole, because a remote system could ask your system to forward protected files that are owned by the uucp user, such as the file L.sys .
If the L.cmds file does not exist, UUCP will use a default set of commands. If the file exists but is empty, remote commands cannot be executed on your system. In this event, the UUCP system can be used only for transferring files.