|
|
|
|
|
|
|
|
MPE/iX Developer's Kit Reference Manual Volume I: HP 3000 MPE/iX Computer Systems > Chapter 3
MPE/iX Library Implementation Considerations
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). 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:
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). 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
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
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. 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
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. Table 3-5 Example of POSIX file security and underlying ACD
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. 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 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, fstat() and stat() return access permissions resulting from an evaluation of the MPE/iX file system security matrix. Evaluation occurs in the following manner:
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. MPE/iX uses the rules described in the following sections when determining how the chmod() function modifies access permissions. 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 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. 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:
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. 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. 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 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). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||
|
|
|
|||||||||
|
|||||||||
