[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]

Files Reference


Permissions File Format for BNU

Purpose

Specifies BNU permissions for remote systems that call or are called by the local system.

Description

The /etc/uucp/Permissions file specifies access for remote systems that use the Basic Networking Utilities (BNU) program to communicate with the local system. The Permissions file contains an entry for each system the local system contacts using BNU. These entries correspond to entries in the /etc/uucp/Systems file or other systems files listed in the /etc/uucp/Sysfiles file with the same format. The Permissions file also contains an entry for each login ID that remote systems are permitted to use when using BNU to log into the local system.

Entries in the Permissions file specify:

The access permissions set in a Permissions file affect remote systems as a whole. They do not pertain to individual users who work on those remote systems. Permissions limiting uucico and uuxqt daemon activities restrict the BNU access to a local system by all users on a specified remote system. The default permissions for sending and receiving files and executing commands are very restrictive. However, the file also provides options that enable you to change these defaults if you want to allow remote systems to have less restricted access to the local system.

Each entry in a Permissions file is a logical line. If an entry is too long to fit on the screen, make the last character in that physical line a \ (backslash), which indicates continuation, and then type the remainder of the entry on the next physical line.

Each logical line contains a required entry specifying a login ID (LOGNAME entry) or the name of a remote system (MACHINE entry), followed by optional option/value pairs separated by either spaces or tabs. Both the LOGNAME and MACHINE entries and the option/value pairs are composed of name/value pairs. Name/value pairs consist of the name of the entry or option followed by an = (equal sign) and the value of the entry or option, with no spaces allowed within the pair.

The Permissions file can also contain comment lines and blank lines. Comment lines begin with a # (pound sign) and occupy the entire physical line. Blank lines are ignored.

Attention: Access permissions set in the Permissions file affect all BNU communications, including those made through the mail facility or over a TCP/IP connection. Entries in a Permissions file do not affect a remote-system user with a valid login on a specified local system. Remote login commands (such as cu, ct, tn, or tip) connect to and log in on a system regardless of the restrictions set up in the localPermissions file. A user with a valid login ID is subject only to the permission codes established for that user's user ID (UID) and group ID (GID).

Note: Examples of using the Permissions file are provided. The examples include issuing default or restricted access to remote systems and combining LOGNAME and MACHINE entries.

LOGNAME and MACHINE Entries

The Permissions file contains two types of required entries:

LOGNAME Specifies the login IDs and access permissions for remote systems that are allowed to contact the local system.
MACHINE Specifies the names and access permissions for the remote systems that the local system can contact.

Both LOGNAME and MACHINE entries specify what the remote system can do on the local system. LOGNAME entries take effect when a remote system contacts the local system. MACHINE entries take effect when the local system contacts a remote system. The permissions given to the remote system in the two types of entries can be the same or different.

For example, if remote system hera contacts local system zeus and logs in as uhera, the LOGNAME=uhera entry in the Permissions file on zeus controls what actions system hera can take on system zeus. If system zeus contacts system hera, the MACHINE=hera entry in the Permissions file on zeus controls what actions system hera can take on system zeus.

The most restrictive LOGNAME and MACHINE entry is an entry without any option/value pairs, which means that the remote system's access to the local system is defined by the default permissions. To override these defaults, include option/value pairs in the entry. The available options are:

These options allow different remote systems different types of access to the local system when using the BNU file transport and command execution programs. A LOGNAME and a MACHINE entry can be combined into a single entry when both include the same options.

LOGNAME Entry

A LOGNAME entry specifies one or more login IDs for remote systems permitted to log into the local system to conduct uucico and uuxqt daemon transactions, plus the access permissions for those remote systems. The login ID can be any valid login name. The LOGNAME entry specifies permissions for the remote system when it contacts the local system. The format of a LOGNAME entry is:

LOGNAME=LoginID[:LoginID . .  .] [Option=Value . . .]

Remote systems log in with one of the IDs listed in the LoginID list. While logged in with that ID, the remote system has the permissions specified in the Option=Value list. The remote system that is calling must be listed in the /etc/uucp/Systems file or an alternative uucico service systems file specified in /etc/uucp/Sysfiles on the local system.

To specify more than one login ID with the same option/value pairs, list them in the same LOGNAME entry, separated by colons but without spaces. To specify multiple login IDs with different option/value pairs, list them in separate LOGNAME entries.

The most restrictive LOGNAME entry is an entry without any option/value pairs. The remote system's access to the local system is then defined by these default permissions:

To override these defaults, include option/value pairs in the LOGNAME entry.

Note: A login ID can appear in only one LOGNAME entry. If there is a single entry for a login ID, that entry alone is sufficient for all remote systems using that login ID.

Attention: Allowing remote systems to log in to the local system with the uucp login ID seriously jeopardizes the security of your system. Remote systems logged in with the uucp ID can display and possibly modify (depending on the other permissions specified in the LOGNAME entry) the local Systems and Permissions files. It is strongly recommended that you create other BNU login IDs for remote systems and reserve the uucp login ID for the person responsible for administering BNU on the local system. Each remote system that contacts the local system should have a unique login ID with a unique UID.

MACHINE Entry

The Permissions file contains a MACHINE entry for each remote system the local system is permitted to contact. The access permissions specified in the MACHINE entry affect the remote system's access to the local system when the local system contacts the remote system. Following is the format of a MACHINE entry:

MACHINE=SystemName[:SystemName .  . .] [Option=Value . . .]

OR

MACHINE=OTHER [Option=Value . . .]

The most restrictive type of MACHINE entry, which uses the default permissions, is:

MACHINE=SystemName[:SystemName .  . .]

The system names are separated by a colon. The entry includes no spaces or tab characters. There are no option/value pairs, indicating that remote system access to the local system is defined by the following default permissions:

To override these defaults, include option/value pairs in the LOGNAME entry.

The SystemName list in a MACHINE entry may include a number of different remote systems. A MACHINE entry can also be:

MACHINE=OTHER [Option=Value . . .]

where the word OTHER represents a system name. This sets up access permissions for remote systems not specified in the existing MACHINE entries in a Permissions file. The MACHINE=OTHER entry is useful in these circumstances:

Rather than create separate MACHINE entries for each of a large group of remote systems, set up one MACHINE=OTHER entry that includes the appropriate commands specified in a COMMANDS option entry. Then, when it becomes necessary to change the default command set, change the list of commands in only one entry rather than in numerous entries. Usually, a MACHINE=OTHER entry also specifies more restrictive option values for the unidentified remote systems.

Note: The local system cannot call any remote system that is not listed by name in a MACHINE entry, unless there is a MACHINE=OTHER entry in the Permissions file on the local system.

Option/Value Pairs

Option/value pairs can be used with the LOGNAME and MACHINE entries. The default permissions are restrictive, but can be changed with one or more of the option/value pairs. These options allow different remote systems different types of access to the local system when using the BNU file transport and command execution programs.

CALLBACK Option

The CALLBACK option, included in LOGNAME entries, specifies that no file transfer transactions will occur until the local system contacts the targeted remote system. The format of the CALLBACK option is either:

CALLBACK=no

OR

CALLBACK=yes

Note: If two systems both include the CALLBACK=yes option in their respective Permissions files, they cannot communicate with each other using BNU.

The default value, CALLBACK=no, specifies that the remote system may contact the local system and begin transferring files without the local system initiating the operations.

For tighter security, use the CALLBACK=yes option to specify that the local system must contact the remote system before the remote system may transfer any files to the local system.

If you include the CALLBACK=yes option in the LOGNAME entry, you must also have a MACHINE entry for that system so that your system can call it back. You can have a MACHINE=OTHER entry to allow your system to call any remote system, including the one for which the CALLBACK=yes option is specified.

The default value, CALLBACK=no, is generally sufficient for most sites.

COMMANDS Option

The COMMANDS option, included only in a MACHINE entry, specifies the commands that the remote systems listed in that MACHINE entry can execute on the local system. The format of the COMMANDS option is either:

COMMANDS=CommandName[:CommandName . . .]

OR

COMMANDS=ALL

The default is COMMANDS=rmail:uucp. Under the default, remote systems can run only the rmail and uucp commands on the local system. (Users enter the mail command, which then calls the rmail command.)

The commands listed in the COMMANDS option override the default. You can also specify path names to those locations on the local system where commands issued by users on remote systems are stored. Specifying path names is useful when the default path of the uuxqt daemon does not include the directory where a command resides.

Note: The default path of the uuxqt daemon includes only the /usr/bin directory.

To allow a certain remote system to execute all available commands on the local system, use the COMMANDS=ALL format. This specifies that the command set available to the designated remote system includes all commands available to users on the local system.

Attention: The COMMANDS option can jeopardize the security of your system. Use it with extreme care.

NOREAD and NOWRITE Options

The NOREAD and NOWRITE options, used in both LOGNAME and MACHINE entries, delineate exceptions to the READ and WRITE options by explicitly forbidding access by the remote system to directories and files on the local system.

The formats of these options follow:

NOREAD=PathName[:PathName . . .]

NOWRITE=PathName[:PathName . . .]

Note: The specifications you enter with the READ, WRITE, NOREAD, and NOWRITE options affect the security of your local system in terms of BNU transactions.

READ and WRITE Options

The READ and WRITE options, used in both LOGNAME and MACHINE entries, specify the path names of directories that theuucico daemon can access when transferring files to or from the local system. You can specify more than one path for uucico daemon activities.

The default location for both the READ and WRITE options is the /var/spool/uucppublic directory (the BNU public directory) on the local system. The formats for these options follow:

READ=PathName[: PathName . . .]

WRITE=PathName[: PathName . . .]

The source file, destination file, or directory must be readable or writable for the other group for the BNU program to access it. Set these permissions with the chmod command. A user without root user authority can take away permissions granted by the READ and WRITE options, but that user cannot grant permissions that are denied by these options.

If the READ and WRITE options are not present in the Permissions file, the BNU program transfers files only to the/var/spool/uucppublic directory. However, if you specify path names in these options, enter the path name for every source and destination, including the /var/spool/uucppublic directory if the remote system is to be permitted access to it.

Attention: Specifications with the READ, WRITE, NOREAD, and NOWRITE options affect the security of your local system in terms of BNU transactions. The subdirectories of directories specified in the READ and WRITE options can also be accessed by the remote system unless these subdirectories are forbidden with the NOREAD or NOWRITE options.

REQUEST Option

The REQUEST option, used in both LOGNAME and MACHINE entries, enables a remote system to ask to receive any queued files containing work that users on the local system have requested to be executed on that remote system. The default is not to allow such requests.

When a remote system contacts the local system to transfer files or execute commands, the remote system may also request permission to receive any files queued on the local system for transfer to or execution on that remote system. This format of the REQUEST option permits such requests:

REQUEST=yes

The default, REQUEST=no, does not have to be entered. This specifies that the remote system cannot ask to receive any work queued for it on the local system. The local system must contact the remote system before transmitting files and execute commands queued on the local system to the remote system.

Use the REQUEST=yes option in both LOGNAME and MACHINE entries to allow remote-system users to transfer files to and execute commands on a local system on demand. Restrict access with the REQUEST=no option so that the local system retains control of file transfers and command executions initiated by remote systems.

Note: Entries in the Permissions file affect only BNU transactions. They do not affect remote-system users with valid logins on a local system.

SENDFILES Option

The default allows the local system to transfer queued work to the remote system only when the local system contacts the remote system. However, when a remote system finishes transferring files to or executing commands on a local system, that local system may try to send queued work to the calling remote system immediately. To enable an immediate transfer, use the following SENDFILES option:

SENDFILES=yes

The SENDFILES=yes option allows the transfer of queued work from the local to the remote system once the remote system has completed its operations. The default value, SENDFILES=call, specifies that local files queued to run on the remote system are sent only when the local system contacts the remote system.

Notes:
  1. The SENDFILES option is ignored when it is included in a MACHINE entry.
  2. Entries in the Permissions file affect only BNU transactions. They do not affect remote-system users with valid logins on a local system.

VALIDATE Option

The VALIDATE option provides more security when including commands in the default command set that could cause damage when executed by a remote system on a local system. Use this option, specified only in a MACHINE entry, in conjunction with a COMMANDS option. The format of the VALIDATE option is:

VALIDATE=LoginName[: LoginName . . .]

The VALIDATE option verifies the identity of the calling remote system. Including this option in a MACHINE entry means that the calling remote system must have a unique login ID and password for file transfers and command executions.

Note: This option is meaningful only when the login ID and password are protected. Giving a remote system a special login and password that provide unlimited file access and remote command-execution ability is equivalent to giving any user on that remote system a normal login and password on the local system, unless the special login and password are well-protected.

The VALIDATE option links a MACHINE entry, which includes a specified COMMANDS option, to a LOGNAME entry associated with a privileged login. The uuxqt daemon, which executes commands on the local system on behalf of users on a remote system, is not running while the remote system is logged in. Therefore, the uuxqt daemon does not know which remote system sent the execution request.

Each remote system permitted to log in to a local system has its own spooling directory on that local system. Only the BNU file transport and command execution programs are allowed to write to these directories. For example, when the uucico daemon transfers execution files from the remote system hera to the local system zeus, it places these files in the /var/spool/uucppublic/hera directory on system zeus.

When the uuxqt daemon attempts to execute the specified commands, it determines the name of the calling remote system (hera) from the path name of the remote-system spooling directory (/var/spool/uucppublic/hera). The daemon then checks for that name in a MACHINE entry in the Permissions file. The daemon also checks for the commands specified in the COMMANDS option in a MACHINE entry to determine whether the requested command can be executed on the local system.

Security

Access Control: Only a user with root authority can edit the Permissions file.

Examples

The following are examples of using the Permissions file.

Providing Default Access to Remote Systems

  1. To provide the default permissions to any system logging in as uucp1, enter:

    LOGNAME=uucp1
    
  2. To provide the default permissions to systems venus, apollo, and athena when called by the local system, enter:

    MACHINE=venus:apollo:athena
    

Providing Less Restricted Access to Remote Systems

  1. The following LOGNAME entry allows remote system merlin to read and write to more directories than just the spool directory:

    LOGNAME=umerlin READ=/ NOREAD=/etc:/usr/sbin/uucp
    WRITE=/home/merlin:/var/spool/uucppublic
    

    A system logging in as user umerlin can read all directories except the /usr/sbin/uucp and /etc directories, but can write only to the /home/merlin and public directories. Because the login name umerlin has access to more information than is standard, BNU validates the system before allowing merlin to log in.

  2. The following example allows remote system hera unrestricted access to system zeus, and shows the relationship between the LOGNAME and MACHINE entries:

    LOGNAME=uhera REQUEST=yes SENDFILES=yes READ
    =/ WRITE=/MACHINE=hera VALIDATE=uhera REQUEST=yes \COMMANDS=ALL READ=/ WRITE=/
    

    The remote system hera may engage in the following uucico and uuxqt transactions with system zeus:

    Because the entries provide system hera with relatively unrestricted access to system zeus, BNU validates the log name before permitting system hera to log in.

Attention: This entry allows unrestricted access to the local system by the remote system listed in the MACHINE entry. This entry can jeopardize the security of your system.

Combining LOGNAME and MACHINE Entries

  1. Following are LOGNAME and MACHINE entries for system hera:

    LOGNAME=uhera REQUEST=yes SENDFILES=yes
    MACHINE=hera VALIDATE=uhera REQUEST=yes COMMANDS=rmail:news:uucp
    

    Since they have the same permissions and apply to the same remote system, these entries can be combined as:

    LOGNAME=uhera SENDFILES=yes REQUEST=yes \
    MACHINE=hera VALIDATE=uhera COMMANDS=rmail:news:uucp
    
  2. LOGNAME and MACHINE entries used for more than one remote system can be combined if they have the same permissions. For example:

    LOGNAME=uucp1 REQUEST=yes SENDFILES=yes
    MACHINE=zeus:apollo:merlin REQUEST=yes COMMANDS=rmail:uucp
    

    can be combined as:

    LOGNAME=uucp1 REQUEST=yes SENDFILES=yes \MACHINE=zeus:apollo:
    merlin COMMANDS=rmail:uucp
    

    Either form of the entries allows systems zeus, apollo, and merlin the same permissions. They can:

Allowing Access to Unnamed Systems

To allow your system to call systems that are not specified by name in a MACHINE entry, use a MACHINE=OTHER entry as follows:

MACHINE=OTHER COMMANDS=rmail

This entry allows your system to call any machine. The machine called will be able to request execution of the rmail command. Otherwise, the default permissions apply.

Permissions File Entries for Three Systems

The following examples show the Permissions files for three connected systems:

On system venus:

LOGNAME=uhera MACHINE=hera \
READ=/ WRITE=/ COMMANDS=ALL \
NOREAD=/usr/secure:/etc/uucp \
NOWRITE=/usr/secure:/etc/uucp
SENDFILES=yes REQUEST=yes VALIDATE=hera

On system hera:

LOGNAME=uvenus MACHINE=venus \
READ=/ WRITE=/ COMMANDS=rmail:who:lp:uucp \
SENDFILES=yes REQUEST=yes
 
LOGNAME=uucp1 MACHINE=OTHER \
REQUEST=yes SENDFILES=yes

On system apollo:

LOGNAME=uhera MACHINE=hera \
READ=/var/spool/uucppublic:/home/hera \
REQUEST=no SENDFILES=call

Given these permissions:

Implementation Specifics

This file is part of the Basic Networking Utilities Program (BNU) in BOS Extensions 1.

Files


/etc/uucp/Permissions file Describes access permissions for remote systems.
/etc/uucp/Systems file Describes accessible remote systems.
/etc/uucp/Sysfiles file Specifies possible alternative files for the /etc/uucp/Systems file.
/var/spool/uucppublic directory Contains files that have been transferred.

Related Information

The chmod command, mail command, rmail command, uucheck command, uucpadm command.

The uucico daemon and uuxqt daemon read the Permissions file.

Configuring BNU, Understanding the BNU File and Directory Structure, Understanding BNU Security in AIX 5L Version 5.1 System Management Guide: Communications and Networks.


[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]