General description

The IPC package provides three facilities for inter-process communication:

• Messages, which are formatted streams that can be sent by processes to any other processes (the following system calls are used: msgget(), msgsnd(), msgrcv(), msgctl()).

• Shared memory, which allows processes to share parts of their virtual address space with other processes (the following system calls are used: shmget(), shmat(), shmdt(), shmctl()).

• Semaphores, which make it possible to synchronize process execution (the following system calls are used: semget(), semop(), semctl()).

The aspects common to the operation of all three facilities are described below under the following sections: The description is divided up among the following sections:

• Creation of a communication element (message queue, shared memory, semaphore)

• Data structures

• Requesting/modifying status information

Note that xxx stands for msg, sem, or shm, respectively.

Each communication element (message queue, shared memory, semaphore) is identified by means of a positive integer, which is assigned by the system on creation of the communication element xxxget(). The user may also specify a numerical key to name a communication element that he or she creates.

Associated with each facility is a table, with entries containing all communication elements for the respective facility.
Each entry is named by means of a user-selected numerical key which serves as its ID.

Creation of a communication element

Each facility has a corresponding system call xxxget() with which a new element can be created or an existing one made available to a process. The parameters of the xxxget() system calls are a user-selected numerical key, key, designating the login name, and a flag

xxxflg.

key

The operating system searches the appropriate table for an entry identified by the key. Processes may call the xxxget() system call with the IPC_PRIVATE key, thus ensuring that an unused entry is returned.

xxxflg

This flag determines whether and how an entry can be accessed, and may influence the access permissions. If the IPC_CREAT flag is set, a new entry is created (if none exists). The required access permissions are OR-ed with IPC_CREAT. The nine right-hand bits in the flag are then set as the access permissions for the new entry. The bit ordering corresponds to that of oflag in the open() system call, even if only read and write permissions are of significance. If an entry already exists with the specified key, the nine right-hand bits of the flag must be a subset of the entry's access permissions; otherwise, the xxxget() system calls will fail. Thus, any permissions that extend beyond those available may not be requested. In order to modify access permissions, the xxxctl() system call must be executed (see below). When the IPC_CREAT flag is additionally OR-ed with the IPC_EXCL flag, xxxget() returns an error if an entry already exists for the key. If the IPC_CREAT flag is not set, an entry must already exist; otherwise, the xxxget() system calls will fail.

The xxxget() system calls return a unique positive identifier (system identifier xxxid) which is selected by the operating system and is used in the other system calls associated with the facility. These identifiers operate in a similar way to the file descriptors, as returned by open(), dup() and pipe(), except that they may be used by all processes that know their value, i.e. inheritance is not required for them to be valid. Each shared memory segment, message queue, and semaphore set is identified by a shared memory identifier (shmid), a semaphore identifier (semid) and the message queue identifier (msqid), respectively.

Data structures

Associated with each identifier is a data structure which contains data related to the operations which may be or have been performed. These data structures (msqid_ds, semid_ds, shmid_ds) are defined in sys/shm.h, sys/sem.h and sys/msg.h. They include the process ID of the last process executed by an operation (send or receive message, access shared memory, etc.) and the time of the last access operation.

Each of the data structures contains both ownership information and an ipc_perm structure (see sys/ipc.h), which are used in conjunction to determine whether or not read/write (read/alter for semaphores) permissions should be granted (or denied) to processes using the IPC facilities. The ipc_perm structure contains the effective user ID and group ID of the process that created the entry (xxx_perm.cuid and xxx_perm.cgid), in addition to a user ID and group ID (xxx_perm.uid and xxx_perm.gid) which may also be set by means of the xxxctl() system call. There is also a bit field for permissions in the mode member of the ipc_perm structure. The values of the bits are given below:

Bit	Meaning
0400	Read (owner)
0200	Write (owner)
0040	Read (group)
0020	Write (group)
0004	Read (others)
0002	Write (others)

The name of the ipc_perm structure is shm_perm, sem_perm, or msg_perm, depending on which facility is being used. In each case, read and write/alter permissions are granted to a process if one or more of the following conditions are true:

• The effective user ID is that of a process with appropriate privileges.

• The effective user ID of the process matches xxx_perm.cuid or xxx_perm.uid in the data structure associated with the IPC identifier, and the appropriate bit for the owner is set in xxx_perm.mode.

• The effective user ID of the process does not match xxx_perm.cuid or xxx_perm.uid but the effective group ID of the process matches xxx_perm.cgid or xxx_perm.gid in the data structure associated with the IPC identifier, and the appropriate bit for group is set in xxx_perm.mode.

• The effective user ID of the process does not match xxx_perm.cuid or xxx_perm.uid, and the effective group ID of the process does not match xxx_perm.cgid or xxx_perm.gid in the data structure associated with the IPC identifier, but the appropriate bit for others is set in xxx_perm.mode.

In all other cases, the permission is denied.

Requesting/modifying status information

xxxctl()

Each facility has a corresponding system call xxxctl(), which allows the status of an entry to be requested, status information to be set, or an entry to be removed from the system.

• If a process requests the status of an entry, the operating system checks whether the process has read permission and then copies data from the table entry to the userspecified structure.

• If a process wishes to reset the parameters of the entry, the operating system checks whether the effective user ID of the process matches the user ID of the entry or the user ID of the entry creator, or whether the effective user ID is that of a process with appropriate privileges. Write permission alone is not sufficient to reset parameters. The operating system copies the user-specified data to the table entry, setting the user ID, group ID, access permissions, and other fields that depend on the type of facility. Since the fields with the user ID and group ID of the entry creator are not modified, the latter always retains control permissions.

• If a process wishes to remove an entry, the operating system checks whether the effective user ID of the process matches one of the user IDs in the ipc_perm structure. It is not possible to access a removed entry with the old identifier.

Note

The IPC facilities must be used with great care, since unused or unneeded IPC members are not always recognized by the operating system. There are no records in the operating system as to which processes access an IPC member. Any process that knows the correct identifier and has access permission can essentially access an IPC member, even if the process has never executed a xxxget() system call. It is therefore not possible for the operating system to implicitly flush IPC structures (e.g. on completion of a process).

IPC facilities should only be used in the case of extreme performance requirements.