Access Control Definitions (ACDs) [ New Features of MPE/iX: Using the Hierarchical File System ] MPE/iX 5.0 Documentation
New Features of MPE/iX: Using the Hierarchical File System
Access Control Definitions (ACDs)
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:
1. Do you have SM capability? If so, you are granted all access to
the file.
2. 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.
3. Are you the owner of the file (your UID matches the UID of the
file)?
a. If there is no ACD associated with the file, you are given
all access permissions to the file and the checking ends.
b. 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.
c. 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.
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):
a. 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.
b. 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.
c. 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.
d. Does an @.@ entry exist? If so, you are granted the access
permissions assigned to that entry. No further checking is
performed.
e. 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.
5. 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.
MPE/iX 5.0 Documentation