 |
» |
|
|
|
MPE/iX file system access is controlled by using access control definitions (ACDs) or the file access matrix. Refer to the Manager's Guide to MPE/iX Security (32650-90474) and User's Guide to MPE/iX Security (32650-90472) manuals for information on restricting file access by using the file access matrix and more details on ACDs. This chapter briefly introduces ACDs because of their relevance to controlling access to files and directories created outside of MPE groups. Because ACDs are now required in some cases, it becomes increasingly important that you understand the MPE/iX ACD facility. | | | |  | NOTE:
ACDs are the main method of controlling access to files, hierarchical directories, and devices. ACDs are automatically assigned to hierarchical directories and to files existing outside of MPE groups.
| | | | |
What is an ACD? | |
ACDs are ordered lists of pairs. 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 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, such as lockwords and the file access matrix. ACDs cannot be placed on root, account, group, or directories. Access modes | |
ACDs control the ability to access and change 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:
- R
Read a file. - W
Write to a file. - L
Lock a file. - A
Append to a file. - X
Execute a file. - CD
Create directory entries. - DD
Delete directory entries. - RD
Read directory entries. - TD
Traverse directory entries. - RACD
Copy or read the ACD associated with the object. - NONE
Deny access.
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 the MPE/iX Commands Reference Manual, Vol. I (32650-90003). User specifications | |
Beginning with MPE/iX Release 4.5, the MPE/iX access control definition (ACD) facility provides three new user specifications. In addition to 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 matches the UID of the file.
- $GROUP
Specifies the file group members of the file or directory. If the user's GID matches the GID of the file, the user is granted the access permissions specified by $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 user is granted an access permission if it appears in both the matching ACD entry 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. In the current release, 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.
How do ACDs work | |
The way ACDs are evaluated has changed as of Release 4.5 as a result of security enhancements. When you attempt to access a file, 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)? If there is no ACD associated with the file, you are given all access permissions to the file and the checking ends.
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.
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): 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 resulting access permissions are only those that are in both the user.account entry and the $GROUP_MASK entry. No further checking is performed.
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.
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 @.account and the $GROUP_MASK entries. No further checking is performed.
Does an @.@ entry exist? If so, you are granted the access permissions assigned to that entry. No further checking is performed.
If you match no ACD entries (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.
ACD examples | |
You assign ACDs using the ALTSEC command. In addition,
files outside of MPE groups are automatically assigned ACDs. Following is an example of an ACD that could be assigned to a text file:
NONE:JIM.DOE,@.ACCT;R,W,X,L:@.PAYROLL;R:@.@
|
The ACD pairs in this example set up the following access controls on the text file: Deny JIM.DOE and all users in the ACCT account access to the file.
Allow read, write, execute, and lock access to users in the PAYROLL account.
Allow read access to everyone else.
Notice that in cases of contradictions, the most specific ACD pair takes precedence. So even though all users are assigned read access (R:@.@), JIM.DOE cannot access the file because he is specifically assigned no access (NONE:JIM.DOE). If the ACD in the above example had a $GROUP_MASK entry (for example, R,X:$GROUP_MASK), then the users in the PAYROLL account would only have read and execute access. The entire ACD would read as follows:
NONE:JIM.DOE,@.ACCT;R,W,X,L:@.PAYROLL;R:@.@;R,X:$GROUP_MASK
|
An example of an ACD for an HFS directory (dir1)
follows:
CD,DD,RD,TD,RACD:@.ACCT;TD:@.@
|
The ACD pairs in this example set up the following access controls on dir1: Allow all users in the ACCT account the ability to create, delete, traverse, and read directory entries in dir1, and to read the ACD.
Allow everyone else the ability to traverse dir1 only.
|
