Access Control Definitions (ACDs)

MPE/iX file system access can be controlled by using access control definitions (ACDs). You can use an ACD to specify permissions and restrictions for access to a file. In addition, ACDs allow you to secure logical devices, device names, and device classes. ACD security replaces all standard file system security that may be in effect for that file or device.




	NOTE: ACDs are the preferred method of controlling access to files, hierarchical directories, and devices in systems that maintain a C2 level of trust. ACDs are automatically assigned to directories and to files existing in directories.

What is an ACD?

ACDs are ordered lists of pairs that define security for a user or group of users. The pairs are made up of access permissions and user specifications that control access to objects. Objects are passive entities that contain or receive information, such as files, directories, and devices. Each entry in the ACD specifies object access permissions granted to a specific user or group of users. In addition to being granted access to an object protected by an ACD, users can also be granted access to read the ACD itself.

ACDs can be applied to any MPE/iX files or hierarchical directories using the ALTSEC command. This command was enhanced to support directories. If a file has an ACD, this method of specifying access to the file takes precedence over other security features.

How do ACDs work

When you attempt to access a file, or other object protected by the file system security facilities, the system checks access permissions in the following order of precedence:

Do you have SM capability? If so, you are granted all access to the file.
Do you have AM capability and does your GID match the GID of the file? If so, you are granted all access to the file.
Are you the owner of the file (your UID matches the UID of the file)?
1. If there is no ACD associated with the file, you are given all access permissions to the file and the checking ends.
2. If there is an ACD associated with the file and there is no $OWNER entry, you are given all access permissions to the file and the checking ends.
3. If there is an ACD associated with the file and that ACD contains the $OWNER entry, you are restricted to the access permissions assigned to $OWNER. (Since you are the file owner, you can always modify the ACD if you need more access permissions than provided by the $OWNER entry.)
If you are not the owner of the file, the system performs the check described in step 4.
Is there an ACD assigned to the file? If there is no ACD assigned to the file, the system performs the checking described in step 5. If there is an ACD, the system performs the checking in the following order (from more specific to less specific):
1. Does your UID match a specific user name entry (for example, ALEX.TECHNLGY). If so, you are granted the access permissions assigned to that entry unless a $GROUP_MASK entry exists. If the $GROUP_MASK entry exists, the matching entry is combined with $GROUP_MASK to determine the actual access permissions. No further checking is performed.
2. Does your GID match the GID of the file? If so, and a $GROUP entry exists, you are granted the access permissions assigned to that entry unless a $GROUP_MASK entry exists. If the $GROUP_MASK entry exists, the resulting access permissions are only those that are in both the $GROUP and the $GROUP_MASK entries. No further checking is performed.
  If you match the $GROUP entry and your GID matches the account portion of an @.account entry, you are granted the access permissions assigned to either ACD entry prior to $GROUP_MASK evaluation.
3. Does your GID match the account portion of an @.account entry? If so, you are granted the access permissions assigned to that entry unless a $GROUP_MASK entry exists. If the $GROUP_MASK entry exists, the resulting access permissions are only those that are in both the $GROUP and the $GROUP_MASK entries. No further checking is performed.
4. Does an @.@ entry exist? If so, you are granted the access permissions assigned to that entry. No further checking is performed.
5. If your name is not found (or if the access mode assigned to you is NONE), you are granted no access to the file, and no further checking is performed.
If there is no ACD, the system uses the file access matrix to check for access permissions.

Access modes

ACD pairs control the ability to access and change MPE files, hierarchical directories, and the files within them. MPE/iX has enhanced the ALTSEC command to support access to directories. The available ACD access modes are as follows:

FILES AND DEVICES

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

DIRECTORIES

CD: Create directory entries.
DD: Delete directory entries.
RD: Read directory entries.
TD: Traverse directory entries.
RACD: Copy or read the ACD permission.
NONE: Deny access.

Table 3-1 File Access Modes

Access Modes	Mnemonic Code	Meaning
READ	R	Allows users to read files.
LOCK	L	Permits a user to prevent concurrent access to a file. Specifically, it permits the use of the `FLOCK` and `FUNLOCK` intrinsics, and the exclusive-access option of the `HPFOPEN` and `FOPEN` intrinsics, all described in the MPE/iX Intrinsics Reference Manual (32650-90028).
APPEND	A	Allows users to add information and disk extents to files, but prohibits them from altering or deleting information already written. This access mode implicitly allows the LOCK (L) access modes described above.
WRITE	W	Allows users general writing access, permitting them to add, delete, or change any information in files. This includes removing entire files from the system with the `PURGE` command. WRITE (W) access also implicitly allows the LOCK (L) and APPEND (A) access modes described previously.
EXECUTE	X	Allows users to run programs stated in files with the `RUN` command or the `CREATE` and `CREATEPROCESS` intrinsics.

The NONE and RACD access modes are available only through an ACD.

Users need appropriate access attributes to access a directory and its contents. For example, the owner of a directory can grant create directory entries (CD) access to other users. Users can only create files or other directories within a directory if they have CD access to the directory.

RD entries access and TD entries access differ as follows. If a user wants to use LISTFILE to list the files in a directory, the user needs RD entries permission for that directory. But, if a user wants to access a file such as /users/jeff/address, the user needs to have TD entries permission for all the directories in the path; that is, /, users, and jeff in this case.

By default, all users can read the contents of and traverse the root directory, all MPE accounts, and all MPE groups. However, to read or write the contents of a file, you must have the appropriate access permission to open the file itself.

Because the root, accounts, and MPE groups are special types of directories on MPE/iX, you cannot control access to them using ACDs. You cannot apply TD, DD, CD, or RD to MPE groups or accounts. You need to use existing mechanisms. For example, use the ALTGROUP command to change save access permissions for MPE groups.

The userspecs part of an ACD pair specifies one user or a group of users assigned the access modes specified in modes part of the same pair. A user is specified as a fully qualified user name in the form username.accountname. For example, JOAN.FINANCE specifies the user JOAN in the account FINANCE.

A wildcard character (@) can be used in place of the user name or both the user name and the account name to specify a group of users. For example, @.FINANCE specifies all users in the account FINANCE, and @.@ specifies all users in all the accounts on the system.

A user who is not specified in any ACD pairs or whose assigned access mode is NONE has no access to the file.

For example, you could define an ACD as follows:

ACD = (R,W:MGR.ACCTING, PETE.TECHNLGY; R:@.PAYROLL; A:@.@)

If this ACD were assigned to a file, it would be interpreted in the following manner:

The users MGR.ACCTING and PETE.TECHNLGY have READ and WRITE access to the file but do not have APPEND, EXECUTE, or RACD access.
All users in the PAYROLL account have READ access to the file but do not have WRITE, APPEND, EXECUTE, or RACD access.
All users on the system have APPEND access to the file but do not have READ, WRITE, EXECUTE, or RACD access.
A file owner has full access to the file.

You use the ALTSEC command to alter access modes for files, hierarchical directories, logical devices, or device classes. For more information about ACD access modes, refer to the ALTSEC command in Chapter 2 of the MPE/iX Reference Supplement (32650-90353).

User specifications

Beginning with MPE/iX Release 4.5, the MPE/iX access control definition (ACD) facility provides three new user specifications. In place of specifying a user (user.account) or set of users (@.account) in a file or directory ACD, you can also use the following designators:

$OWNER: Specifies the file owner. The file owner is granted the access permissions specified by $OWNER. A user is a file owner if the user's UID (in the form user.account) matches the UID of the file. The owner can be changed from the initial creator programmatically.
$GROUP: Specifies the file group members of the file or directory. If the user's GID (in the form account) matches the GID of the file, the user is granted the access permission assigned to $GROUP.
$GROUP_MASK: Restricts all ACD entries except for $OWNER and @.@. In this case, if a user matches a user.account entry, $GROUP entry, or @.account entry, the matching entry is granted the access if it appears in both $GROUP and $GROUP_MASK. An ACD with a $GROUP_MASK entry must also have a $GROUP entry. $GROUP_MASK is provided to integrate the POSIX definition of security with the more robust security provided by MPE/iX ACDs.

These new user specifications modify the manner in which the file system checks access permissions when an ACD is associated with a file.

Required ACDs

Prior to release 4.5, the MPE/iX ACD facility provided an optional security facility to replace MPE/iX standard file system security features. Beginning with release 4.5, ACDs are required on the following system objects:

All hierarchical directories
All files under hierarchical directories
All files directly under MPE/iX groups where the file GID does not match the GID of the account and group in which the file is located.

Because ACDs are now required in some cases, it becomes increasingly important that you understand the MPE/iX ACD facility. This section provides a summary of the enhancements made to the MPE/iX ACD facility. This section either supplements or replaces the descriptions of ACDs found the Controlling System Activity (32650-90155).

HFS Object creation

Creating an object, which is creating an entry for a file or directory within a directory, requires that a process have traverse directory (TD) and create directory (CD) access to the object's parent directory and SF capability. For an MPE group, SAVE access is equivalent to create directory access (see "SAVE access in MPE groups").

Users with SM capability can create files and directories anywhere on the system. Users without SM capability can create files and directories outside their logon account in any directory that they can traverse and to which they have been granted create directory access.

HFS Object deletion

To delete a file or subdirectory from a directory, you must have DD access to the directory. For files in MPE groups, you only need WRITE access to the file. For directories in MPE groups, you only need SAVE access to the MPE group.

HFS File renaming

Any user with the proper access can rename a file. To rename a file, you must have both CD and DD access. DD is required to delete the old entry from the directory where the file resides, and CD is required to create the new directory entry.

You can rename a file from one directory to another if you have DD access to the directory in which the file is located and CD access to the directory where you want the renamed file to reside.

Users with SM capability can rename files anywhere on the system. To rename a file from an MPE group in one account to an MPE group in another account, you must have SM capability.

If you rename a file that does not have an ACD from an MPE group to a directory that is not an MPE group, an ACD is automatically generated for it. Otherwise, the file would no longer be protected by the file access matrix.

If you rename a file (that does not have an ACD) from an MPE group to another MPE group outside the original account, an ACD is automatically generated for it. The file's GID would no longer match the parent group's GID and would not be protected by the file access matrix.

File owner

A file (or directory) owner has complete access to the file unless the user is restricted by a $OWNER ACD entry. Now that there is a $OWNER ACD entry, you can restrict the file access of the file owner.

For example, MGR.PAYROLL is the creator (owner) of the file MYFILE. On Releases 3.0 and 4.0, the owner's access cannot be restricted by an ACD or the file access matrix. So on Release 3.0 and 4.0 systems, MGR.PAYROLL still has all the access permissions on this file even if an ACD pair specifies only read permission (R:MGR.PAYROLL). As of Release 4.5, the access of the owner can be restricted by using the $OWNER ACD entry. Assigning R:$OWNER restricts the owner to having read permission only.