In reality no new system calls were added, although eight new APIs were added to the system call interface. The new APIs utilize the previously existing sys_ipc system call demultiplexer in sys_i386.c to dispatch the new IPC related calls. Currently only the Intel 32-bit architecture has been modified.
The semget_secure, msgget_secure, and shmget_secure calls allow a caller to request an IPC object with a given key and a given SID. If the caller has create access but the key is already allocated to an IPC object with a different SID, the caller is returned EACCES.
The msgrcv and msgrcv_secure calls skip messages that are labeled with a SID for which the calling process does not have receive access rather than return EACCES. This may result in access checks being performed and denial of access being audited for messages whose existence is not even apparent to the calling process when a) the msgrcv call is used, or the msgrcv_secure call is used with a SID of SECSID_WILD or SECSID_NULL, and b) messages exist on the queue for which the process does not have receive permission, and c) access has been revoked from the process for the queue or from messages to which it had access when it called msgrcv or msgrcv_secure. In that (unusual) case, the calling process will also wait indefinitely for a message.
A beneficial implication of the interactions between the read, write, receive, send, and enqueue permissions and independent SIDs for message queues and individual messages is that policies may be developed which allow restricted multi-level message queues. These may be desired to create a convenient one-way communication mechanism for processes. Policy writers, of course, need to carefully consider the the implications of such a one-way channel if it is desired and implemented.