id = msgget(key, IPC_CREAT | S_IRUSR | S_IWUSR); if (id == -1) errExit("msgget"); 45.3

928
Chapter 45
in the get system call used to create the object, but can be changed subsequently
using the 
IPC_SET
operation.
As with files, permissions are broken into three categories—owner (also known
as user), group, and other—and it is possible to specify different permissions for each
category. There are, however, some notable differences from the scheme used for files:
z
Only read and write permissions are meaningful for IPC objects. (For sema-
phores, write permission is commonly referred to as alter permission.) Execute
permission is meaningless, and is ignored when performing most access
checks.
z
Permission checks are made according to a process’s effective user ID, effective
group IDs, and supplementary group IDs. (This contrasts with file-system per-
mission checks on Linux, which are performed using the process’s file-system
IDs, as described in Section 9.5.)
The precise rules governing the permissions a process is granted on an IPC object
are as follows:
1. If the process is privileged (
CAP_IPC_OWNER
), then all permissions are granted on
the IPC object.
2. If the effective user ID of the process matches either the owner or the creator
user ID of the IPC object, then the process is granted the permissions defined
for the owner (user) of the object.
3. If the effective group ID or any of the supplementary group IDs of the process
match either the owner group ID or the creator group ID of the IPC object,
then the process is granted the group permissions defined for the object.
4. Otherwise, the process is granted the permissions defined for other.
In the kernel code, the above tests are constructed so that the test to see
whether a process is privileged is performed only if the process is not granted
the permissions it needs via one of the other tests. This is done to avoid unnec-
essarily setting the 
ASU
process accounting flag, which indicates that the process
made use of superuser privileges (Section 28.1).
Note that neither the use of the 
IPC_PRIVATE
key value nor the presence of
IPC_EXCL
flag has any bearing on which processes may access an IPC object;
such access is determined solely by the ownership and permissions of the object.
How read and write permissions are interpreted for an object, and whether they
are required, depend on the type of object and on the operation being performed.
When a get call is performed to obtain the identifier of an existing IPC object,
an initial permission check is made to ascertain whether the permissions specified
in the flags argument are compatible with those on the existing object. If not, then
the get call fails with the error 
EACCES
. (Except as otherwise noted, this error code is
also returned when permissions are denied in each of the cases listed below.) To
illustrate, consider the example of two different users in the same group, with one
user creating a message queue using the following call:
msgget(key, IPC_CREAT | S_IRUSR | S_IWUSR | S_IRGRP);
/* rw-r----- */

Introduction to System V IPC
929
An attempt by the second user to obtain an identifier for this message queue using
the following call would fail, since the user is not permitted write access to the mes-
sage queue:
msgget(key, S_IRUSR | S_IWUSR);
The second user could bypass this check by specifying 0 for the second argument
of the msgget() call, in which case an error would occur only when the program
attempted an operation requiring write permission on the IPC object (e.g., writing
a message with msgsnd()).
The get call represents the one case where execute permission is not ignored.
Even though it has no meaning for IPC objects, if execute permission is
requested in a get call for an existing object, then a check is made to see if that
permission is granted.
The permissions required for other common operations are as follows:
z
To retrieve information from the object (e.g., to read a message from a message
queue, obtain the value of a semaphore, or attach a shared memory segment
for read access) requires read permission.
z
To update information within the object (e.g., to write a message to a message
queue, change the value of a semaphore, or attach a shared memory segment
for write access) requires write permission.
z
To obtain a copy of the associated data structure for an IPC object (the 
IPC_STAT
ctl operation) requires read permission.
z
To remove an IPC object (the 
IPC_RMID
ctl operation) or change its associated
data structure (the 
IPC_SET
ctl operation) requires neither read nor write per-
mission. Rather, the calling process must either be privileged (
CAP_SYS_ADMIN
) or
have an effective user ID matching either the owner user ID or the creator user
ID of the object (otherwise, the error 
EPERM
results).
It is possible to set the permissions on an IPC object so that the owner or creator
can no longer use 
IPC_STAT
to obtain the associated data structure containing
the object permissions (which means that the object won’t be displayed by the
ipcs(1) command described in Section 45.6), although 
IPC_SET
can still be used
to change them.
Various other mechanism-specific operations require read or write permission, or
the 
CAP_IPC_OWNER
capability. We note the required permissions in the following
chapters as the operations are described.

tải về 6.93 Mb.

Chia sẻ với bạn bè của bạn: