HP 3000 Manuals HP 3000 Manuals
Access Control
This section provides an overview of implementation considerations that
you should understand when using access control features as they are
implemented in the POSIX/iX library.
MPE/iX security features have been enhanced to provide full support for
security features defined by the POSIX.1 standard. MPE/iX supports
additional access security features, but they remain largely transparent
to your application.
You may need to understand these underlying access security features if
your application accesses files that were not created by the POSIX/iX
library functions, or if the security of those files was modified by
MPE/iX CI commands or system intrinsics.
For more information about how file access permissions are used in a
POSIX.1 environment, refer to chapter 3, "Files and Directories", in The
POSIX.1 Standard - A Programmer's Guide (36430-90003).
For more information about MPE/iX implementation of POSIX.1 security
standards, refer to User's Guide to MPE/iX Security (32650-90472).
MPE/iX Access Control Definitions
Access permissions defined by the POSIX.1 standard are fully supported in
the POSIX/iX library through the use of the MPE/iX access control
definition (ACD) facility. POSIX.1 security is fully integrated with
MPE/iX security. Except in cases described below, ACD access control
remains transparent when accessed through POSIX/iX library functions.
The POSIX/iX library automatically provides translation between the
POSIX.1 view of access permission and the MPE/iX view of access
permission.
ACDs are required for the following file system objects:
* All hierarchical directories.
* All files under hierarchical directories.
* All files directly under MPE accounts.
* 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 resides.
A file or hierarchical directory created by POSIX/iX library functions is
automatically assigned an ACD.
For more information about MPE/iX ACDs, refer to New Features of MPE/iX:
Using the Hierarchical File System (32650-90351).
Mapping Between POSIX.1 and ACD Access Permissions
The following table describes the correspondence between POSIX.1 file
access permissions and MPE/iX ACD access permissions.
Table 3-2. Mapping between POSIX.1 and ACD File Access Permissions
--------------------------------------------------------------------------------------------
| | |
| POSIX.1 Access | ACD Access Permissions |
| Permissions | |
| | |
--------------------------------------------------------------------------------------------
| | |
| Read | ACD read (R) access |
| | |
--------------------------------------------------------------------------------------------
| | |
| Write | ACD write (W) access |
| | |
--------------------------------------------------------------------------------------------
| | |
| Execute | ACD execute (X) access |
| | |
--------------------------------------------------------------------------------------------
The following table describes the correspondence between POSIX.1
directory access permissions and MPE/iX ACD access permissions.
Table 3-3. Mapping between POSIX.1 and ACD Directory Access Permissions
---------------------------------------------------------------------------------------------
| | |
| POSIX.1 Access Permissions | ACD Access Permissions |
| | |
---------------------------------------------------------------------------------------------
| | |
| Read | ACD read directory entries (RD) access |
| | |
---------------------------------------------------------------------------------------------
| | |
| Write | Both ACD create directory entries (CD) and |
| | ACD delete directory entries (DD) access |
| | |
---------------------------------------------------------------------------------------------
| | |
| Execute | ACD traverse directory entries (TD) access |
| | |
---------------------------------------------------------------------------------------------
Write access to a directory is implemented by two MPE/iX ACD access
modes, create directory entry (CD) and delete directory entry (DD).
Setting or modifying write access permission to a directory using
POSIX/iX library functions always modifies both ACD access modes. Both
CD and DD access modes must be specified in order for a POSIX/iX library
function to have write access to a hierarchical directory.
MPE/iX CI commands and system intrinsics allow you to remove either the
CD or DD access mode. When this occurs, both fstat() and stat() indicate
that write access permission is no longer granted to the process;
however, if only DD access is specified, a process can delete directory
entries but cannot create directory entries. Likewise, if only CD access
is specified, a process can create directory entries but cannot delete
directory entries.
Mapping Between POSIX.1 and ACD File User Classes
The following table describes the correspondence between the POSIX.1 file
user classes and MPE/iX ACD user specifications.
Table 3-4. Mapping between POSIX.1 and ACD User Classes
---------------------------------------------------------------------------------------------
| | |
| POSIX.1 File Classes | ACD User Specifications |
| | |
---------------------------------------------------------------------------------------------
| | |
| File owner | $OWNER |
| | |
---------------------------------------------------------------------------------------------
| | |
| File group | $GROUP and $GROUP_MASK |
| | |
---------------------------------------------------------------------------------------------
| | |
| File other | @.@ |
| | |
---------------------------------------------------------------------------------------------
The $OWNER ACD entry specifies the owner of the file or directory. A
user is a file or directory owner if the user's effective UID matches the
UID of the file.
The $GROUP ACD entry specifies the group members of the file or
directory. A user is a file or directory group member if the user's
effective GID matches the GID of the file.
The $GROUP_MASK entry restricts all ACD entries except for $OWNER and
@.@. In this case, if a user matches a user.account entry, an @.account
entry, or a $GROUP entry, the user is granted only the access permissions
that appear in both the matching entry and the $GROUP_MASK entry. An ACD
with a $GROUP_MASK entry must also contain a $GROUP entry. The
$GROUP_MASK entry serves to integrate the POSIX definition of security
with the more robust security provided by MPE/iX ACDs.
The @.@ ACD entry specifies the file other class members of the file or
directory who are not members of the file owner class or the file group
class.
A file or hierarchical directory created by POSIX/iX library functions is
automatically assigned an ACD containing the four MPE/iX user
specifications $OWNER, $GROUP, $GROUP_MASK, and @.@. The access
permissions associated with each of the four user specifications are
initialized from the mode parameter and modified by the calling process's
file creation mask. The access modes associated with the $GROUP_MASK
entry are initialized to the same access modes associated with the $GROUP
entry.
The following example shows the correspondence between a POSIX view of
access permissions and the underlying ACD.
Example of POSIX file security and underlying ACD
-------------------------------------------------------------------------------------------
| |
| File Owner Class File Group Class File Other Class |
| |
-------------------------------------------------------------------------------------------
| |
| rwx r-x --x |
| |
| R,W,X,RACD:$OWNER R,X,RACD:$GROUP R,X, X:@.@ |
| RACD:$GROUP_MASK |
| |
-------------------------------------------------------------------------------------------
If the ACD Has Been Modified or Removed
If you are accessing files that were not created through POSIX/iX library
functions, or whose security was modified by MPE/iX commands or system
intrinsics, the ACDs may be missing any or all of the four ACD user
specification entries $OWNER, $GROUP, $GROUP_MASK, and @.@. ACDs missing
any of these four ACD user specification entries still support access
control as defined by the POSIX.1 standard since they can be regarded as
containing default values for the missing ACD entries.
Summary of fstat() and stat() Behavior
MPE/iX uses the rules described in the following sections when
determining the access permissions returned by calls to the fstat() and
stat() functions.
If the File or Directory has an ACD.
If the ACD contains a $OWNER entry, fstat() and stat() return for the
file owner class the access permissions associated with the $OWNER entry.
If the ACD contains no $OWNER entry, fstat() and stat() return for the
file owner class the access permissions of both read and write access.
Execute access is also returned for the file owner class if any ACD entry
specifies execute access to the file.
If the ACD contains an @.@ entry, fstat() and stat() return for the file
other class the access permissions associated with the @.@ entry. If the
ACD contains no @.@ entry, fstat() and stat() return for the file other
class access permissions of NONE.
If the ACD contains a $GROUP_MASK entry, fstat() and stat() return for
the file group class the access permissions associated with the
$GROUP_MASK entry. If the ACD contains no $GROUP_MASK entry, fstat() and
stat() return for the file group class the access permissions resulting
from ORing all file group class members (all user.account entries,
@.account entries, and the $GROUP entry). If the $GROUP entry and the
@.account entry that corresponds to the file GID are both missing, and an
@.@ entry exists, the permissions associated with the @.@ entry are
included in the calculation.
If the File Does Not Have an ACD.
If the file does not have an ACD, fstat() and stat() return access
permissions resulting from an evaluation of the MPE/iX file system
security matrix. Evaluation occurs in the following manner:
* The file owner class access permissions returned by fstat() and
stat() indicate both read and write access. Execute access is
also indicated if any user has execute access to the file.
* The file group class access permissions returned by fstat() and
stat() are the result of ORing together the access permissions
associated with the file system security matrix AC and ANY user
specifications.
* The file other class access permissions returned by fstat() and
stat() are the access permissions associated with the file system
security matrix ANY user specification.
The Root Directory, MPE/iX Accounts, and MPE/iX Groups.
For the root directory and MPE/iX accounts, the file owner class, file
group class, and file other class access permissions returned by fstat()
and stat() indicate read and execute access.
For MPE/iX groups, the file owner class and file group class access
permissions returned by fstat() and stat() indicate read, write, and
execute access. The file other access permissions indicate read and
execute access.
Summary of chmod() Behavior
MPE/iX uses the rules described in the following sections when
determining how the chmod() function modifies access permissions.
If the File or Directory has an ACD.
If the ACD contains the $GROUP entry, and does not contain user.account
or @.account entries, the $GROUP entry is assigned the file group class
access permissions passed by chmod(), plus RACD access.
If the ACD contains the $GROUP entry as well as user.account or @.account
entries, the $GROUP entry is not affect by chmod(). In this case, only
the $GROUP_MASK is assigned the file group class access permissions
passed by chmod(), plus RACD access.
If the ACD does not contain the $GROUP entry, and does not contain
user.account or @.account entries, the $GROUP entry is created with the
file group class access permissions passed by chmod(), plus RACD access.
If the ACD does not contain the $GROUP entry but contains user.account
entries and/or @.account entries, the following rules apply, in order of
precedence:
* If an @.account entry exists where account matches the GID of the
file, the $GROUP entry is created with the access permissions of
that @.account entry.
* If no @.account entry exists where account matches the GID of the
file, and an @.@ entry exists, $GROUP is created with the access
permissions of the @.@ entry.
* If no @.account entry exists where account matches the GID of the
file, and no @.@ entry exists, $GROUP is created with access
permissions of NONE.
If the ACD contains the $GROUP_MASK entry, the $GROUP_MASK entry is
assigned the file group class access permissions passed by chmod(), plus
RACD access. If the ACD does not contain the $GROUP_MASK entry, the
$GROUP_MASK entry is created with the file group class access permissions
passed by chmod(), plus RACD access.
If the ACD contains a $OWNER entry, the $OWNER entry is assigned the file
owner class access permissions passed in chmod(), plus RACD access. If
the ACD contains no $OWNER entry, a $OWNER entry is created with the file
owner class access permissions passed in chmod(), plus RACD access.
If the ACD contains the @.@ entry, the @.@ entry is assigned the file
other class access permissions passed by chmod(), plus RACD access. If
the ACD contains no @.@ entry, the @.@ entry is created with the file
other class access permissions passed in chmod(), plus RACD access.
If the File Does Not Have an ACD.
When chmod() is invoked on a file that does not have an ACD, an ACD is
created with the following user specifications and access permissions:
* The $OWNER entry is assigned the file owner class access
permissions passed by chmod(), plus RACD access.
* Both the $GROUP and $GROUP_MASK entries are assigned the file
group class access permissions passed by chmod(), plus RACD
access.
* The @.@ entry is assigned the file other class access permissions
passed by chmod(), plus RACD access.
The Root Directory, MPE/iX Accounts, and MPE/iX Groups.
Attempts to use chmod() to modify access permissions of the root
directory, MPE/iX accounts, or MPE/iX groups result in an error, with
errno set to EINVAL.
Determining a Process's Access to a File or Directory
For information about MPE/iX implementation of POSIX.1 security
standards, refer to User's Guide to MPE/iX Security (32650-90472).
Refer to chapter 9, "Handling Security on MPE/iX", in New Features of
MPE/iX: Using the Hierarchical File System (32650-90351) for a thorough
description of how MPE/iX determines a process's access to a file or
directory.
Returning Information about Access Permissions
An additional MPE/iX ACD access permission, read ACD (RACD) access, is
used to restrict a user from reading access permissions of a directory or
file that is assigned an ACD. The POSIX/iX library does not allow
manipulation of the RACD access permission. By default, all users are
given RACD access to all objects created through POSIX/iX library
functions. This default allows queries of directory and file access
permissions to occur through the stat() and fstat() functions without
error.
MPE/iX provides facilities outside the POSIX/iX library to manipulate the
RACD access permission of a directory or file. If a process attempts to
invoke the fstat() or stat() function on a directory or file with an ACD
that does not allow RACD access to that process, both functions return an
error, with errno set to EPERM.
You can modify RACD access to a file or directory using the MPE/iX CI
command ALTSEC.
MPE/iX Save Files (SF) Capability
The user associated with a process must have save files (SF) capability
to create an entry in a file. In POSIX.1 terminology, SF capability acts
as an additional access control mechanism. A process must, therefore,
have SF capability to successfully create files or hierarchical
directories. The SF capability is an MPE/iX capability assigned to a
user through the MPE/iX CI commands NEWUSER or ALTUSER.
MPE/iX Lockwords
MPE/iX provides an additional file security feature, file lockwords, that
is not accessible through POSIX/iX library functions; however, file
lockword security is suppressed for all files and directories that
contain ACDs. Lockwords can be encountered only on files located
directly under MPE/iX groups.
Attempts to open an existing file that has an MPE/iX lockword result in
an error, with errno set to EACCESS. Attempts to modify the access
permissions of an existing file that has an MPE/iX lockword also result
in an error.
For more information about MPE/iX lockwords, refer to User's Guide to
MPE/iX Security (32650-90472).