212 lines
8.4 KiB
HTML
212 lines
8.4 KiB
HTML
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<meta name="Copyright" content="Copyright (c) 2006 by IBM Corporation">
|
||
|
|
<title>Identifier Based Services</title>
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<!-- Begin Header Records ========================================= -->
|
||
|
|
<!-- UNIX3 SCRIPT A converted by B2H R4.1 (346) (CMS) by V2DCIJB at -->
|
||
|
|
<!-- RCHVMW2 on 1 Jun 1999 at 16:14:49 -->
|
||
|
|
<!-- File created for V5R2 -->
|
||
|
|
<!-- 031112 JETAYLOR did NOT replace API and/or Exit listings with -->
|
||
|
|
<!-- pagegenerator output from javascript array -->
|
||
|
|
<!-- because repeated APIs were missing (ftok, QlgFtok) from 1st,2nd lists -->
|
||
|
|
<!-- End Header Records -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="../rzahg/ic.css">
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<a name="Top_Of_Page"></a>
|
||
|
|
<!-- Java sync-link -->
|
||
|
|
<script type="text/javascript" language="Javascript" src="../rzahg/synch.js">
|
||
|
|
</script>
|
||
|
|
|
||
|
|
<h2>Identifier Based Services</h2>
|
||
|
|
|
||
|
|
<p>Although each IPC service provides a specific type of interprocess
|
||
|
|
communication, the three identifier based services share many similarities.
|
||
|
|
Each service defines a mechanism through which its communications take place.
|
||
|
|
For message queues, that mechanism is a message queue; for semaphore sets, it
|
||
|
|
is a semaphore set; and for shared memory, it is a shared memory segment. These
|
||
|
|
mechanisms are identified by a unique positive integer called, respectively, a
|
||
|
|
message queue identifier (<em>msqid</em>), a semaphore set identifier
|
||
|
|
(<em>semid</em>), and a shared memory identifier (<em>shmid</em>).</p>
|
||
|
|
|
||
|
|
<p><strong>Note:</strong> Throughout the Interprocess Communication APIs, the
|
||
|
|
term thread is used extensively. This does not mean that IPC objects can be
|
||
|
|
used only between threads within one process, but rather that authorization
|
||
|
|
checks and waits occur for the calling thread within a process.</p>
|
||
|
|
|
||
|
|
<p>Associated with each identifier is a data structure that contains state
|
||
|
|
information for the IPC mechanism, as well as ownership and permissions
|
||
|
|
information. The ownership and permissions information is defined in a
|
||
|
|
structure in the <strong><sys/ipc.h></strong> header file as follows:</p>
|
||
|
|
|
||
|
|
<pre>
|
||
|
|
typedef struct ipc_perm {
|
||
|
|
uid_t uid; /* Owner's user ID */
|
||
|
|
gid_t gid; /* Owner's group ID */
|
||
|
|
uid_t cuid; /* Creator's user ID */
|
||
|
|
gid_t cgid; /* Creator's group ID */
|
||
|
|
mode_t mode; /* Access modes */
|
||
|
|
} ipc_perm_t;
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>This structure is similar to a file permissions structure, and is
|
||
|
|
initialized by the thread that creates the IPC mechanism. It is then checked by
|
||
|
|
all subsequent IPC operations to determine if the requesting thread has the
|
||
|
|
required permissions to perform the operation.</p>
|
||
|
|
|
||
|
|
<p>To get an identifier, a thread must either create a new IPC mechanism or
|
||
|
|
access an existing mechanism. This is done through the <strong>
|
||
|
|
msgget()</strong>, <strong>semget()</strong>, and <strong>shmget()</strong>
|
||
|
|
functions. Each get operation takes as input a <em>key</em> parameter and
|
||
|
|
returns an identifier. Each get operation also takes a <em>flag</em> parameter.
|
||
|
|
This <em>flag</em> parameter contains the IPC permissions for the mechanism as
|
||
|
|
well as bits that determine whether or not a new mechanism is created. The
|
||
|
|
rules for whether a new mechanism is created or an existing one is referred to
|
||
|
|
are as follows:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>Specifying a <em>key</em> of IPC_PRIVATE guarantees a new mechanism is
|
||
|
|
created.<br>
|
||
|
|
<br>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>Setting the IPC_CREAT bit in the <em>flag</em> parameter creates a new
|
||
|
|
mechanism for the specified <em>key</em> if one does not already exist. If an
|
||
|
|
existing mechanism is found, its identifier is returned.<br>
|
||
|
|
<br>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>Setting both IPC_CREAT and IPC_EXCL creates a new mechanism for the
|
||
|
|
specified <em>key</em> only if a mechanism does not already exist. If an
|
||
|
|
existing mechanism is found, an error is returned.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>When a message queue, semaphore set, or shared memory segment is created,
|
||
|
|
the thread that creates it determines how it can be accessed. The thread does
|
||
|
|
this by passing mode information in the low-order 9 bits of the <em>flag</em>
|
||
|
|
parameter on the <strong>msgget()</strong>, <strong>semget()</strong>, or
|
||
|
|
<strong>shmget()</strong> function call. This information is used to initialize
|
||
|
|
the <samp>mode</samp> field in the <samp>ipc_perm</samp> structure. The values of the
|
||
|
|
bits are given below in hexadecimal notation:</p>
|
||
|
|
|
||
|
|
<table cellpadding="5">
|
||
|
|
<!-- cols="15 85" -->
|
||
|
|
<tr>
|
||
|
|
<th align="left" valign="top">Bit</th>
|
||
|
|
<th align="left" valign="top">Meaning</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td align="left" valign="top"><em>X'0100'</em></td>
|
||
|
|
<td align="left" valign="top">Read by user</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td align="left" valign="top"><em>X'0080'</em></td>
|
||
|
|
<td align="left" valign="top">Write by user</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td align="left" valign="top"><em>X'0020'</em></td>
|
||
|
|
<td align="left" valign="top">Read by group</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td align="left" valign="top"><em>X'0010'</em></td>
|
||
|
|
<td align="left" valign="top">Write by group</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td align="left" valign="top"><em>X'0004'</em></td>
|
||
|
|
<td align="left" valign="top">Read by others</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td align="left" valign="top"><em>X'0002'</em></td>
|
||
|
|
<td align="left" valign="top">Write by others</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
|
||
|
|
<p>Subsequent IPC operations do a permission test on the calling thread before
|
||
|
|
allowing the thread to perform the requested operation. This permission test is
|
||
|
|
done in one of three forms:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>For the <strong>msgget()</strong>, <strong>semget()</strong>, or <strong>
|
||
|
|
shmget()</strong> calls that are accessing an existing IPC mechanism, the
|
||
|
|
caller's <em>flag</em> parameter is checked to make sure it does not specify
|
||
|
|
access bits that are not in the <samp>mode</samp> field of the existing IPC
|
||
|
|
mechanism's <samp>ipc_perm</samp> structure. If the <em>flag</em> parameter does
|
||
|
|
not contain any bits that are not in the <samp>mode</samp> field, permission is
|
||
|
|
granted.<br>
|
||
|
|
<br>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>For most of the other IPC APIs, the effective user ID and effective group
|
||
|
|
ID of the thread are retrieved, and these values are compared with the data in
|
||
|
|
the <samp>ipc_perm</samp> structure as follows:<br>
|
||
|
|
<br>
|
||
|
|
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>If the effective user ID equals either the <samp>uid</samp> or the <samp>
|
||
|
|
cuid</samp> field for the IPC mechanism, and if the appropriate access bit is on
|
||
|
|
in the <samp>mode</samp> field (either <samp>Read by user</samp> or <samp>Write by
|
||
|
|
user</samp>, depending on the operation being requested), permission is
|
||
|
|
granted.<br>
|
||
|
|
<br>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>If the effective group ID equals either the <samp>gid</samp> or the <samp>
|
||
|
|
cgid</samp> field for the IPC mechanism, and if the appropriate access bit is on
|
||
|
|
in the <samp>mode</samp> field (either <samp>Read by group</samp> or <samp>Write by
|
||
|
|
group</samp>), permission is granted.<br>
|
||
|
|
<br>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>If none of the above tests are true, and if the appropriate access bit is
|
||
|
|
on for others (either <samp>Read by others</samp> or <samp>Write by others</samp>),
|
||
|
|
permission is granted.<br>
|
||
|
|
<br>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>For the <strong>msgctl()</strong>, <strong>semctl()</strong>, or <strong>
|
||
|
|
shmctl()</strong> APIs, some values of the <em>cmd</em> parameter require the
|
||
|
|
caller to be the owner or creator of the IPC object, or have appropriate
|
||
|
|
privileges. The values of <em>cmd</em> that this rule applies to depends on the
|
||
|
|
API. This is shown in the API descriptions for <strong>msgctl()</strong>,
|
||
|
|
<strong>semctl()</strong>, and <strong>shmctl()</strong>.</li>
|
||
|
|
</ul>
|
||
|
|
<br>
|
||
|
|
<p>The Identifier Based Services are divided into the following subcategories:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="unix3a1.htm">Message Queue Functions</a><br></li>
|
||
|
|
<li><a href="unix3a2.htm">Semaphore Set Functions</a><br></li>
|
||
|
|
<li><a href="unix3a3.htm">Shared Memory Functions</a><br></li>
|
||
|
|
<li><a href="unix3a4.htm">IPC Key Generation Functions</a><br></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
|
||
|
|
<hr>
|
||
|
|
<center>
|
||
|
|
<table cellpadding="2" cellspacing="2">
|
||
|
|
<tr align="center">
|
||
|
|
<td valign="middle" align="center"><a href="#Top_Of_Page">Top</a> | <a href=
|
||
|
|
"unix.htm">UNIX-Type APIs</a> | <a href="aplist.htm">APIs by category</a></td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</center>
|
||
|
|
</body>
|
||
|
|
</html>
|
||
|
|
|