The /etc/uucp/Permissions file specifies the permissions that remote computers have for login, file access, and command execution. Some options restrict the remote computer's ability to request files and its ability to receive files that are queued by the local system. Another option is available that specifies the commands that a remote system can run on the local computer.
Each entry is a logical line, with physical lines terminated by a backslash (\) to indicate continuation. Entries are composed of options that are delimited by a blank space. Each option is a name-value pair in the following format:
Values can be colon-separated lists. No blank space is allowed within an option assignment.
Comment lines begin with a pound sign (#) and occupy the entire line up to a newline character. Blank lines are ignored, even within multiple-line entries.
The types of Permissions file entries are as follows:
LOGNAME entries contain a –LOGNAME option. MACHINE entries contain a –MACHINE option. One entry can contain both options.
When using the Permissions file to restrict the level of access that is granted to remote computers, you should consider the following:
When a remote computer calls your computer and requests to receive a file, this request can be granted or be denied. The –REQUEST option specifies whether the remote computer can request to set up file transfers from your computer. The string REQUEST=yes specifies that the remote computer can request to transfer files from your computer. The string REQUEST=no specifies that the remote computer cannot request to receive files from your computer. REQUEST=no, the default value, is used if the –REQUEST option is not specified. The –REQUEST option can appear in either a LOGNAME entry, so that the remote computer calls you, or a MACHINE entry, so that you call the remote computer.
When a remote computer calls your computer and completes its work, the remote computer can attempt to retrieve the work that your computer has queued for it. The –SENDFILES option specifies whether your computer can send the work that is queued for the remote computer.
The string SENDFILES=yes specifies that your computer can send the work that is queued for the remote computer if it is logged in as one of the names in the –LOGNAME option. This string is mandatory if you have entered Never in the Time field of /etc/uucp/Systems. This designation sets up your local system in passive mode, but it is not allowed to initiate a call to this particular remote computer. See UUCP /etc/uucp/Systems File for more information.
The string SENDFILES=call specifies that files that are queued in your computer are 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 sent to remote computers. If the option is used with a MACHINE entry, the option is ignored.
This option enables you to designate a unique UUCP node name for your computer in addition to its TCP/IP host name, as returned by the hostname command. For instance, if you have unknowingly given your host the same name as that of some other system, you can set the –MYNAME option of the Permissions file. Suppose that you want your organization to be known as widget. If all your modems are connected to a system with the host name gadget, you can have an entry in gadget's Permissions file that reads as follows:
service=uucico systems=Systems.cico:Systems dialers=Dialers.cico:Dialers \ devices=Devices.cico:Devices service=cu systems=Systems.cu:Systems \ dialers=Dialers.cu:Dialers \ devices=Devices.cu:Devices
Now, the system world can log in to the system gadget as if it were logging in to widget. In order for system world to know you also by the aliased name widget when you call it, you can have an entry that reads as follows:
You can also use the –MYNAME option for testing purposes, as this option allows your system to call itself. However, because this option could be used to mask the real identity of a system, you should use the –VALIDATE option, as described in UUCP -VALIDATE Option.
These options specify the various parts of the file system that uucico can read from or write to. You can designate –READ and –WRITE options 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 strings READ=/ and WRITE=/ specify permission to access any file that can be accessed by a local user with Other permissions.
The value of these entries is a colon-separated list of path names. The –READ option is for requesting files, and the –WRITE option is for depositing files. One of the values must be the prefix of any full path name of a file entering or exiting. To grant permission to deposit files in /usr/news as well as in the public directory, use the following values with the –WRITE option:
If the –READ and –WRITE options are used, all path names must be specified because the path names are not added to the default list. For instance, if the /usr/news path name were the only path specified in a –WRITE option, permission to deposit files in the public directory would be denied.
Be careful which directories you make accessible for reading and writing by remote systems. For example, the /etc directory contains many critical system files. Remote users should not have permission to deposit files in this directory.
The –NOREAD and –NOWRITE options specify exceptions to the –READ and –WRITE options or defaults. The following entry permits reading any file except those files in the /etc directory (and its subdirectories) Remember, these options are prefixes.
READ=/ NOREAD=/etc WRITE=/var/spool/uucppublic
This entry permits writing only to the default /var/spool/uucppublic directory. –NOWRITE works in the same manner as the –NOREAD option. You can use the –NOREAD and –NOWRITE options in both LOGNAME and MACHINE entries.
You can use the –CALLBACK option in LOGNAME entries to specify that no transaction occurs until the calling system is called back. The reasons to set up –CALLBACK are as follows:
For security purposes – If you call back a system, you can be sure it is the right system.
The string CALLBACK=yes specifies that your computer must call back the remote computer before any file transfers can occur.
The default for the –CALLBACK option is CALLBACK=no. If you set CALLBACK to yes, the permissions that affect the rest of the conversation must be specified in the MACHINE entry that corresponds to the caller. Do not specify these permissions in the LOGNAME, or in the LOGNAME entry that the remote system might have set for your host.
Caution - The –COMMANDS option can compromise the security of your system. Use this option with extreme care.
You can use the –COMMANDS option in MACHINE entries to specify the commands that a remote computer can run on your system. The uux program generates remote execution requests and queues the requests to be transferred to the remote computer. Files and commands are sent to the target computer for remote execution, which is an exception to the rule that MACHINE entries apply only when your system calls out.
Note that –COMMANDS is not used in a LOGNAME entry. –COMMANDS in MACHINE entries defines command permissions, whether you call the remote system or the remote system calls you.
The string COMMANDS=rmail specifies the default commands that a remote computer can run on your computer. 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 that are named owl, raven, hawk, and dove can now run rmail, rnews, and lp on your computer.
In addition to the names as just specified, you can have full path names of commands. For example, the following entry specifies that command rmail uses the default search path.
The default search path for UUCP is /bin and /usr/bin. When the remote computer specifies rnews or /usr/local/rnews for the command to be run, /usr/local/rnews is run regardless of the default path. Likewise, /usr/local/lp is the lp command that is run.
Including the ALL value in the list means that any command from the remote computers that are specified in the entry is run. If you use this value, you give the remote computers full access to your system.
Caution - This value allows far more access than normal users have. You should use this value only when both systems are at the same site, are closely connected, and the users are trusted.
Here is the string with the ALL value added:
This string illustrates two points:
The path names that are specified for rnews and lp are used (instead of the default) if the requested command does not contain the full path names for rnews or lp.
You should use the –VALIDATE option whenever you specify potentially dangerous commands, such as cat and uucp with the –COMMANDS option. Any command that reads or writes files is potentially dangerous to local security when the command is run by the UUCP remote execution daemon (uuxqt).
Use the –VALIDATE option in conjunction with the –COMMANDS option whenever you specify commands that are potentially dangerous to your system's security. –VALIDATE is merely an added level of security on top of the –COMMANDS option, though it is a more secure way to open command access than ALL.
–VALIDATE provides a certain degree of verification of the caller's identity by cross-checking the host name of a calling system against the login name it uses. The following string ensures that if any system other than widget or gadget tries to log in as Uwidget, the connection is refused.
The –VALIDATE option requires privileged computers to have a unique login and password for UUCP transactions. An important aspect of this validation is that the login and password that are associated with this entry are protected. If an outsider obtains that information, that particular –VALIDATE option can no longer be considered secure.
Carefully consider which remote computers you are granting privileged logins and passwords 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:
If an outsider obtains the uucpfriend login and password, masquerading is easy.
But what does this entry have to do with the –COMMANDS option, which appears only in MACHINE entries? This entry links the MACHINE entry (and –COMMANDS option) with a LOGNAME entry that is associated with a privileged login. This link is needed because the execution daemon is not running while the remote computer is logged in. Actually, the link is an asynchronous process that does not know which computer sent the execution request. Therefore, the real question is: How does your computer know where the execution files came from?
Each remote computer has its own spool directory on your local system. These spool directories have write permission that is given only to the 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. Or, if the computer name does not appear in the Permissions file, the default list is used.
This example shows the relationship between the MACHINE and LOGNAME entries:
MACHINE=eagle:owl:hawk REQUEST=yes \ COMMANDS=rmail:/usr/local/rnews \ READ=/ WRITE=/ LOGNAME=uucpz VALIDATE=eagle:owl:hawk \ REQUEST=yes SENDFILES=yes \ READ=/ WRITE=/
The value in the –COMMANDS option means that remote users can run rmail and /usr/local/rnews.
In the first entry, you must assume that when you want to call one of the computers that is listed, you are really calling either eagle, owl, or hawk. Therefore, any files that are 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 therefore have to validate that the computer has the privileged login uucpz.
You might want to specify different option values for remote systems that are not mentioned in specific MACHINE entries. The need might arise when many computers are calling your host, and the command set changes from time to time. The name OTHER for the computer name is used for this entry as shown in this example:
MACHINE=OTHER \ COMMANDS=rmail:rnews:/usr/local/Photo:/usr/local/xp
All other options that are available for the MACHINE entry can also be set for the computers that are not mentioned in other MACHINE entries.
You can combine MACHINE and LOGNAME entries into a single entry when the common options are the same. For example, the two sets of entries that follow share the same –REQUEST, –READ, and –WRITE options:
MACHINE=eagle:owl:hawk REQUEST=yes \ READ=/ WRITE=/
LOGNAME=uupz REQUEST=yes SENDFILES=yes \ READ=/ WRITE=/
MACHINE=eagle:owl:hawk REQUEST=yes \ logname=uucpz SENDFILES-yes \ READ=/ WRITE=/
Combining MACHINE and LOGNAME entries makes the Permissions file more manageable and efficient.
When sending files through a series of systems, the intermediary systems must have the command uucp among their –COMMANDS options. If you type the following command, the forwarding operation works only if system willow permits system oak to run the uucp program.
% uucp sample.txt oak\!willow\!pine\!/usr/spool/uucppublic
The system oak also must permit your system to run the uucp program. The system pine, as the last system designated, does not have to permit the uucp command because the system is not doing any forwarding operations. Systems are not normally set up this way.