HP 3000 Manuals HP 3000 Manuals
MPE/iX Security Components
This section describes some existing security features then introduces
security enhancements and their implications for system administrators.
Access control definitions
MPE/iX continues to support access control definitions (ACDs). ACDs are
ordered lists of pairs (access permissions and user specification) that
specify access to objects. An ACD takes precedence over certain other
security features, such as lockwords and the file security matrix.
Files located outside of MPE groups and HFS directories are automatically
assigned ACDs when they are created. By default, RACD (read ACD) is
assigned to all users and only the owner can access the file or
directory. The ACD can be modified using the ALTSEC command but the ACD
cannot be deleted.
When files are renamed to a group outside the original account, they are
automatically assigned ACDs. When a file located in an MPE group has its
group ID (GID) changed to the GID of another account, an ACD is
automatically assigned. The ACD can be modified using the ALTSEC command
but it cannot be deleted.
If you are unfamiliar with ACDs, refer to Chapter 9 "Handling Security on
MPE/iX" of this manual. For more information on manipulating ACDs, refer
to the ALTSEC command in the MPE/iX Commands Reference Manual, Vol. I
(32650-90003).
Access modes
ACD pairs control the access and manipulation of HFS directories and the
files within them. MPE/iX has enhanced ACDs to support four new ACD
access modes. The ACD access modes are as follows:
Permissions common to files and directories.
RACD Copy or read the ACD.
NONE Deny access.
File permissions.
R Read a file.
W Write to a file.
L Lock a file.
A Append to a file.
X Execute a file.
Directory permissions.
CD Create directory entries.
DD Delete directory entries.
RD Read directory entries.
TD Traverse directory entries.
User specifications.
The following new ACD user specifications are provided:
* $OWNER specifies users whose UID maches the file owner of the
object. $OWNER enables file owners to voluntarily limit their
access to an object. For example, file owners can grant
themselves read-only access to a file to guard against
accidentally modifying the file. The $OWNER user specification is
the only way for file owners to limit their access to an object.
* $GROUP specifies users with a GID that matches the current group
ID of the object. $GROUP permits dynamic reference to the GID of
an object. This is useful because GIDs of files and directories
can be changed programmatically or using chown in the MPE/iX
shell. When the GID of a file is changed, it is not necessary to
modify an ACD to correct file sharing.
* $GROUP_MASK restricts the access granted by ACD entries other than
$OWNER and @.@. When an ACD contains a $GROUP_MASK entry, a user
is granted a specific access mode only if it is listed in the ACD
entry the user matches (in the form user.account, @.account, and
$GROUP) and in the $GROUP_MASK entry.
You can use traditional user specifications to describe individuals or
groups of users:
* username.accountname specifies a single user
* @.accountname specifies all users associated with the accountname
account.
Capabilities
SM and AM capability are checked before ACDs or the file access matrix.
Users with SM capability have unrestricted access to all file system
objects.
Users with SM capability can create files outside of the logon
account/group structure because they have implied CD access. Those
without SM capability can only create files in directories where they
explicitly have CD permission. Users must also have SF capability to
save files in directories and SAVE access to save files in an MPE group.
Account managers may not have total access to all objects in their
account. Having AM capability enables a process to access file system
objects if the GID of an object (GID represented by an account name)
matches the GID (logon account) of the process. What this means is that
there may be cases where the GID of a file or directory within an account
has been changed programmatically or using chown() in the MPE/iX shell so
that an AM for that account cannot access it, or the file or directory
was created by a user with a different GID.
Lockwords
A file's creator can assign or remove a file lockword. Lockwords can
only be assigned to files, not to directories. Lockwords can only be
assigned to files in MPE groups.
All users are required to provide lockwords for files protected by active
lockwords. Lockwords must be supplied by being embedded in MPE syntax
file names or in response to lockword prompting.
There is no way to specify a lockword using HFS syntax. Any attempt to
open a file with a lockword using HFS syntax results in a lockword
violation. The user is not prompted for the lockword.
Although system managers can assign ACDs to any file or directory in the
system, they must supply the lockword for any lockword-protected files
before they can assign an ACD. Once the file has an ACD, the ACD
supercedes the lockword.
Restricting Access to /tmp
Because any user can build files in /tmp, you can restrict access by
using the ALTSEC command.
Creating files and directories
Users can create files or directories in any HFS directory which they can
traverse and to which they have been granted create directory entries
access. Only users with SM capability can create files in MPE groups
outside the logon account or in the root directory. Users can create
files in MPE groups in their logon account and in other groups where they
have SAVE access. A user must have SF capability to create a file or
directory. The MPE group must have SAVE access assigned to it before
files and directories can be created at any level under it.
Renaming files and directories
Users with sufficient access can rename or move a file between
directories. The file's creator is no longer the only user able to do
this. Only the file creator can perform a rename operation if the
lockword of the file is being changed.
To rename a file across directory boundaries, a user must have DD access
to delete the old directory entry and CD access to create the new
directory entry. TD access is also needed to all name components that
make up the source and target pathnames. SAVE access is required to
rename a file from an MPE group in one account to an MPE group in another
account.
Deleting files or directories
To delete files or directories in HFS directories, users must have DD
access to the parent directory. During the design of the HFS, it was
decided that any user that could create a directory in a group should
also be able to purge that directory. Since all that is required to
build a directory is SAVE access to the group, that is also what is
required to purge the directory. The directory must be "empty", meaning
that it contains only the . and .. entries. For historical
compatibility, to delete files in MPE groups, users must have WRITE
access to the file.