GT.M uses several types of shared resources to implement concurrent access to databases. The first GT.M process to open a database file creates IPC resources (semaphores and shared memory) required for concurrent use by other GT.M processes, and in the course of operations GT.M processes create files (journal, backup, snapshot) which are required by other GT.M processes. In order to provide access to database files required by M language commands and administration operations consistent with file permissions based on the user, group and world classes, the shared resources created by GT.M may have different ownership, groups and permissions from their associated database files as described below. As an example of the complexity involved, consider a first process opening a database based on its group access permissions. In other words, the database file is owned by a different userid from the semaphores and shared memory created by that first process. Now, if the userid owning the database file is not a member of the database file's group, a process of the userid owning the database file can only have access to the shared resources if the shared resources have world access permissions or if they have a group that is guaranteed to be shared by all processes accessing the database file, even if that group is different from the database file's own group. Again, although FIS strongly recommends against running GT.M processes as root, a root first process opening the database file must still be able to open it although it may not be the owner of the database file or even in its group - but it must ensure access to other, non-root processes. Some things to keep in mind:
Even a process with read-only access to the database file requires read-write access to the shared memory control structures and semaphores.
Creating and renaming files (for example, journal files) requires write access to both the files and the directories in which they reside.
If you use additional layered security (such as Access Control Lists or SELinux), you must ensure that you analyze these cases in the context of configuring that layered security.
GT.M takes a number of factors into account to determine the resulting permissions:
The owner/group/other permissions of the database file or object directory
The owner of the database file or object directory
The group of the database file or object directory
The group memberships of the database file's or object directory's owner
The owner/group/other permissions of the libgtmshr file
The group of the libgtmshr file
The effective user id of the creating process
The effective group id of the creating process
The group memberships of the creating process' user
The following table describes how these factors are combined to determine the permissions to use:
Database File* Permissions |
Opening process is owner of database file*? |
Owner is member of group of database file*? |
Opening process is a member of database file* group? |
Execution of GT.M restricted to members of a group? |
|---|---|---|---|---|
|
Group of Resource |
IPC Permissions** |
File Permissions*** |
||
|
For Autorelink permissions: * : Routine directory ** : rtnobj shared memory and relinkctl shared memory permissions. Note that rtnobj shared memory permissions have the *** : relinkctl file permissions | ||||
| -r--r--rw- | N | Y | N | N |
| Current group of process | -rw-rw-rw- | -rw-rw-rw- | ||
| -*--rw---- | N | Y | Y | - |
| Group of database file | -rw-rw---- | -rw-rw---- | ||
| -r*-r*-r*- | - | - | Y | - |
| Group of database file | -rw-rw-rw | -r*-r*-r* | ||
| -rw-rw-r* | - | - | N | - |
| Current group of process | -rw-rw-rw | -rw-rw-rw | ||
| -rw-rw-rw | - | - | N | - |
| Current group of process | -rw-rw-rw | -rw-rw-rw | ||
| -rw-rw-rw | Y | Y | - | - |
| Group of database file | -rw-rw-rw | -r*-r*---- | ||
| -r*-r*---- | Y | N | - | N |
| Current group of process | -rw-rw-rw- | -rw-rw-rw- | ||
| -r*-r*---- | Y | N | - | Y |
| Group to which GT.M is restricted | -rw-rw---- | -rw-rw---- | ||
| -r*-r*---- | - | Y | - | - |
| Group of database file | -rw-rw---- | -r*-r*---- | ||
| -r*-r*---- | - | N | - | N |
| Group of database file | -rw-rw-rw- | -rw-rw-rw- | ||
| -r*-r*---- | - | N | - | Y |
| Group to which GT.M is restricted | -rw-rw---- | -rw-rw---- | ||
| ----r*---- | - | N | - | - |
| Group of database file | -rw-rw---- | ----r*---- | ||
| -r*------- | Y | - | - | - |
| Current group of process | -rw------- | -rw------- | ||
The resulting group ownership and permissions are found by matching the database file permissions, then determining which question columns produce the correct "Y" or "N" answer; "-" answers are "don't care".
An asterisk ("*") in the Database File Permissions matches writable or not writable. An asterisk in the Resulting File Permissions means that GT.M uses the write permissions from the database file.
GT.M determines group restrictions by examining the permissions of the libgtmshr file. If it is not executable to others, GT.M treats it as restricted to members of the group of the libgtmshr file.
Group membership can either be established by the operating system's group configuration or by the effective group id of the process.
A GT.M process requires read access in order to perform write access to database file - a file permission of write access without read access is an error.
GT.M treats the "root" user the same as other users, except that when it is not the file owner and not a member of the group, it is treated as if it were a member of the group.
"Execution of GT.M restricted to members of a group" may remove "other" permissions.