Connecting to other computers with UUCP

Limiting access with the Permissions file

If other machines will be dialing into your system, the Permissions file (/usr/lib/uucp/Permissions) specifies the permissions that remote computers have with respect to login, file access, and command execution. There are options that restrict the remote computer's ability to request files and its ability to receive files queued by the local site. Other options specify the commands that a remote site can execute on the local computer.

NOTE: The following command provides a useful interpretation of the Permissions file:

/usr/lib/uucp/uucheck -v | more

Structuring Permissions file entries

Each entry is a logical line with physical lines terminated by a ``\'' to indicate continuation. Entries are made up of options delimited by spaces. Each option is a name-value pair in the following format:


NOTE: No spaces are allowed within an option assignment. This means that any continuations in an option assignment cannot have spaces before the ``\'' or at the start of the next line.

Comment lines begin with a number sign (#) and they occupy the entire line up to a newline character. Blank lines are ignored (even within multi-line entries).

There are two types of Permissions file entries:

specifies the permissions that take effect when a remote computer calls your computer.

specifies permissions that take effect when your computer calls a remote computer.
In this way it is possible not only to define permissions for sites calling your system, but permissions for when your site calls other machines.

Permissions file restrictions

When using the Permissions file to restrict the level of access granted to remote computers:

NOTE: LOGNAME and MACHINE are often combined for convenience, but they function independently. For example, if a remote system logs in as nuucp, uucico will read the first entry containing LOGNAME=nuucp without regard to the MACHINE name.

Permissions options

This section describes each option, specifies how it is used, and lists its default values.


specifies whether the remote computer can request file transfers from your computer. When a remote computer requests a file, this request can be granted or denied. The following string specifies that the remote computer can transfer of files from your computer:
The following string specifies that the remote computer cannot request files from your computer:
which is the default value (it is used if the REQUEST option is not specified). The REQUEST option can appear in either a LOGNAME (remote calls you) entry or a MACHINE (you call remote) entry.


specifies whether your computer can send the work queued for the remote computer. When a remote computer calls your computer and completes its work, it may ask if your computer has work queued for it.

The following string specifies that your computer can send the work that is queued for the remote computer as long as the remote computer is logged in as one of the names in the LOGNAME option:

This string is mandatory if your computer is in a passive mode with respect to the remote computer.

The following string specifies that files queued in your computer be sent only when your computer calls the remote computer:

The call value is the default for the SENDFILES option. This option is only significant in LOGNAME entries because MACHINE entries apply when calls are made out to remote computers. If this option is used with a MACHINE entry, it is ignored.


specify the various parts of the filesystem that uucico can read from or write to. The READ and WRITE options can be used with either MACHINE or LOGNAME entries.

The default for both the READ and WRITE options is the uucppublic directory as shown in the following strings:

The following strings specify permission to access any file that can be read or written by UUCP.
The value of these entries is a colon-separated list of pathnames. The READ option is for requesting files, and the WRITE option for depositing files. One of the values must be the prefix of any full pathname of a file coming in or going out.

NOTE: READ and WRITE options do not affect the actual permissions of a file or directory. For example, a directory with permissions of 700 only permits the owner to access it, and cannot be read or written by the UUCP user, no matter what access options are defined in the Permissions file. In addition to the proper READ and WRITE options, the paths must grant appropriate permissions to the UUCP user.

To grant permission to deposit files in /usr/tmp as well as the public directory, the following values would be used with the WRITE option:

It should be pointed out that if the READ and WRITE options are used, all pathnames must be specified because the pathnames are not added to the default list. For instance, if the /usr/news pathname was the only one specified in a WRITE option, permission to deposit files in the public directory would be denied.

You should be careful which directories you make accessible for reading and writing by remote systems. For example, you probably do not want remote computers to be able to write over your /etc/passwd file so /etc should not be open to writes.


specify exceptions to the READ and WRITE options or defaults. The following strings would permit reading any file except those in the /etc directory (and its subdirectories -- remember, these are prefixes) and writing only to the default /usr/spool/uucppublic directory:
NOWRITE works in the same manner as the NOREAD option. The NOREAD and NOWRITE options can be used in both LOGNAME and MACHINE entries.


specifies in LOGNAME entries that no transaction takes place until the calling system is called back. There are two examples of when you would use CALLBACK. From a security standpoint, if you call back a machine you can be sure it is the machine it says it is. If you are doing long data transmissions, you can choose the machine that is billed for the longer call.

The following string specifies that your computer must call the remote computer back before any file transfers take place:

The default for the CALLBACK option is:
The CALLBACK option is rarely used. If two sites have this option set for each other, a conversation never gets started.


specifies the commands in MACHINE entries that a remote computer can execute on your computer. This affects the security of your system; use it with extreme care.

The uux program generates remote execution requests and queues them to be transferred to the remote computer. Files and a command are sent to the target computer for remote execution. Note that COMMANDS is not used in a LOGNAME entry; COMMANDS in MACHINE entries define command permissions whether you call the remote system or it calls you.

The default command that a remote computer can execute on your computer is:

If a command string is used in a MACHINE entry, the default commands are overridden. For instance, the following entry overrides the COMMAND default so that the computers owl, raven, hawk, and dove can now execute rmail, rnews, and lp on your computer:
   MACHINE=owl:raven:hawk:dove \
Full pathnames of commands can also be used. For example, the following command specifies that command rmail uses the default path:
The default paths for your computer are /bin, /usr/bin, and /usr/lbin. When the remote machine specifies rnews or /usr/lbin/rnews for the command to be executed, /usr/lbin/rnews is executed regardless of the default path. Similarly, /usr/bin/lp is the lp command that is executed.

Including the ALL value in the list means that any command from the remote computer specified in the entry is executed. If you use this value, you give the remote computer full access to your computer. Be careful, this allows far more access than normal users have.

The following string illustrates two points:



is used in conjunction with the COMMANDS option in LOGNAME entries when specifying commands that are potentially dangerous to your computer's security. It provides a certain degree of verification of the caller's identity. The use of the VALIDATE option requires that privileged computers have a unique login or password for UUCP transactions. An important aspect of this validation is that the login or password associated with this entry be protected. If an outsider gets that information, that particular VALIDATE option can no longer be considered secure. (VALIDATE is merely an added level of security to the COMMANDS option, though it is a more secure way to open command access than ALL.)

Careful consideration should be given to providing a remote computer with a privileged login and password for UUCP transactions. Giving a remote computer a special login and password with file access and remote execution capability is like giving anyone on that computer a normal login and password on your computer. Therefore, if you cannot trust someone on the remote computer, do not provide that computer with a privileged login and password.

The following LOGNAME entry specifies that if one of the remote computers that claims to be eagle, owl, or hawk logs in on your computer, it must have used the login uucpfriend.

   LOGNAME=uucpfriend VALIDATE=eagle:owl:hawk
As can be seen, if an outsider gets the uucpfriend login or password, masquerading is trivial.

VALIDATE increases security by linking the MACHINE entry (and COMMANDS option) with a LOGNAME entry associated with a privileged login. This link is needed because the execution daemon is not running while the remote machine is logged in. In fact, it is an asynchronous process with no knowledge of what machine sent the execution request. How does your system know where the execution files came from?

Each remote computer has its own spool directory on your computer. These spool directories have write permission given only to UUCP programs. The execution files from the remote computer are put in its spool directory after being transferred to your computer. When the uuxqt daemon runs, it can use the spool directory name to find the MACHINE entry in the Permissions file and get the COMMANDS list. If the computer name does not appear in the Permissions file, the default list is used.

The following example shows the relationship between the MACHINE and LOGNAME entries:

   MACHINE=eagle:owl:hawk REQUEST=yes \
   COMMANDS=rmail:/usr/local/bin/lc \
   READ=/  WRITE=/

LOGNAME=uucpz VALIDATE=eagle:owl:hawk \ REQUEST=yes SENDFILES=yes \ READ=/ WRITE=/

The COMMANDS option line shows that remote mail and /usr/local/bin/lc can be executed by remote users.

In the MACHINE entry, you must make the assumption that when you want to call one of the computers listed, you are really calling eagle, owl, or hawk. Any files put into one of the eagle, owl, or hawk spool directories is put there by one of those computers. If a remote computer logs in and says that it is one of these three computers, its execution files are also put in the privileged spool directory. You should validate that the computer has the privileged login uucpz.

Entries for OTHER systems

You may want to specify different option values for machines or logins that are not mentioned in specific MACHINE or LOGNAME entries. This may occur when there are many computers calling in that have the same set of permissions. The special name OTHER for the computer name can be used in a MACHINE or LOGNAME entry as follows:

LOGNAME=OTHER \ REQUEST=yes SENDFILES=yes \ READ=/usr/spool/uucppublic \ WRITE=/usr/spool/uucppublic

All options that can be set for specific machines or logins can be used with the OTHER value, although the use of the VALIDATE option makes little sense.

Combining MACHINE and LOGNAME entries

It is possible to combine MACHINE and LOGNAME entries into a single entry where the common options are the same. For example, the following two entries share the same REQUEST, READ, and WRITE options:
   MACHINE=eagle:owl:hawk REQUEST=yes \
     READ=/  WRITE=/


These two entries can be merged as follows:
   MACHINE=eagle:owl:hawk REQUEST=yes \
   LOGNAME=uucpz SENDFILES=yes \
     READ=/  WRITE=/

Next topic: How UUCP works
Previous topic: Modems used with a local network switch

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003