MPE/iX Security Components

This section describes some existing security features then introduces security enhancements and their implications for system administrators.

Access control definitions

MPE/iX continues to support access control definitions (ACDs). ACDs are ordered lists of pairs (access permissions and user specification) that specify access to objects. An ACD takes precedence over certain other security features, such as lockwords and the file security matrix.

Files located outside of MPE groups and HFS directories are automatically assigned ACDs when they are created. By default, RACD (read ACD) is assigned to all users and only the owner can access the file or directory. The ACD can be modified using the ALTSEC command but the ACD cannot be deleted.

When files are renamed to a group outside the original account, they are automatically assigned ACDs. When a file located in an MPE group has its group ID (GID) changed to the GID of another account, an ACD is automatically assigned. The ACD can be modified using the ALTSEC command but it cannot be deleted.

If you are unfamiliar with ACDs, refer to Chapter 9 "Handling Security on MPE/iX" of this manual. For more information on manipulating ACDs, refer to the ALTSEC command in the MPE/iX Commands Reference Manual, Vol. I (32650-90003).

Access modes

ACD pairs control the access and manipulation of HFS directories and the files within them. MPE/iX has enhanced ACDs to support four new ACD access modes. The ACD access modes are as follows:

Permissions common to files and directories

RACD: Copy or read the ACD.
NONE: Deny access.

File permissions

R: Read a file.
W: Write to a file.
L: Lock a file.
A: Append to a file.
X: Execute a file.

Directory permissions

CD: Create directory entries.
DD: Delete directory entries.
RD: Read directory entries.
TD: Traverse directory entries.

User specifications

The following new ACD user specifications are provided:

$OWNER specifies users whose UID maches the file owner of the object. $OWNER enables file owners to voluntarily limit their access to an object. For example, file owners can grant themselves read-only access to a file to guard against accidentally modifying the file. The $OWNER user specification is the only way for file owners to limit their access to an object.
$GROUP specifies users with a GID that matches the current group ID of the object. $GROUP permits dynamic reference to the GID of an object. This is useful because GIDs of files and directories can be changed programmatically or using chown in the MPE/iX shell. When the GID of a file is changed, it is not necessary to modify an ACD to correct file sharing.
$GROUP_MASK restricts the access granted by ACD entries other than $OWNER and @.@. When an ACD contains a $GROUP_MASK entry, a user is granted a specific access mode only if it is listed in the ACD entry the user matches (in the form user.account, @.account, and $GROUP) and in the $GROUP_MASK entry.

You can use traditional user specifications to describe individuals or groups of users:

username.accountname specifies a single user
@.accountname specifies all users associated with the accountname account.

Capabilities

SM and AM capability are checked before ACDs or the file access matrix. Users with SM capability have unrestricted access to all file system objects.

Users with SM capability can create files outside of the logon account/group structure because they have implied CD access. Those without SM capability can only create files in directories where they explicitly have CD permission. Users must also have SF capability to save files in directories and SAVE access to save files in an MPE group.

Account managers may not have total access to all objects in their account. Having AM capability enables a process to access file system objects if the GID of an object (GID represented by an account name) matches the GID (logon account) of the process. What this means is that there may be cases where the GID of a file or directory within an account has been changed programmatically or using chown() in the MPE/iX shell so that an AM for that account cannot access it, or the file or directory was created by a user with a different GID.

Lockwords

A file's creator can assign or remove a file lockword. Lockwords can only be assigned to files, not to directories. Lockwords can only be assigned to files in MPE groups.

All users are required to provide lockwords for files protected by active lockwords. Lockwords must be supplied by being embedded in MPE syntax file names or in response to lockword prompting.

There is no way to specify a lockword using HFS syntax. Any attempt to open a file with a lockword using HFS syntax results in a lockword violation. The user is not prompted for the lockword.

Although system managers can assign ACDs to any file or directory in the system, they must supply the lockword for any lockword-protected files before they can assign an ACD. Once the file has an ACD, the ACD supercedes the lockword.

Restricting Access to /tmp

Because any user can build files in /tmp, you can restrict access by using the ALTSECcommand.

Creating files and directories

Users can create files or directories in any HFS directory which they can traverse and to which they have been granted create directory entries access. Only users with SM capability can create files in MPE groups outside the logon account or in the root directory. Users can create files in MPE groups in their logon account and in other groups where they have SAVE access. A user must have SF capability to create a file or directory. The MPE group must have SAVE access assigned to it before files and directories can be created at any level under it.

Renaming files and directories

Users with sufficient access can rename or move a file between directories. The file's creator is no longer the only user able to do this. Only the file creator can perform a rename operation if the lockword of the file is being changed.

To rename a file across directory boundaries, a user must have DD access to delete the old directory entry and CD access to create the new directory entry. TD access is also needed to all name components that make up the source and target pathnames. SAVE access is required to rename a file from an MPE group in one account to an MPE group in another account.

Deleting files or directories

To delete files or directories in HFS directories, users must have DD access to the parent directory. During the design of the HFS, it was decided that any user that could create a directory in a group should also be able to purge that directory. Since all that is required to build a directory is SAVE access to the group, that is also what is required to purge the directory. The directory must be "empty", meaning that it contains only the . and .. entries. For historical compatibility, to delete files in MPE groups, users must have WRITE access to the file.