iofunc_check_access()
Check access permissions
Synopsis:
#include <sys/iofunc.h>
int iofunc_check_access(
resmgr_context_t *ctp,
const iofunc_attr_t *attr,
mode_t checkmode,
const struct _client_info *info );
Arguments:
- ctp
- A pointer to a resmgr_context_t structure that the resource-manager library uses to pass context information between functions.
- attr
- A pointer to the iofunc_attr_t structure that defines the characteristics of the device that's associated with the resource manager.
- checkmode
- The type and access permissions that you want to check for the resource. For more information, see below.
- info
- A pointer to a _client_info structure that contains the information about a client connection. For information about this structure, see ConnectClientInfo(). You can get this structure by calling iofunc_client_info_ext().
Library:
libc
Use the -l c option to qcc to link against this library. This library is usually included automatically.
Description:
The iofunc_check_access() function verifies that the client is allowed access to the resource, as specified by a combination of who the client is (info), and the resource attributes attr->mode, attr->uid and attr->gid. Access is tested based upon the checkmode parameter.
The checkmode parameter determines which checks are done. It's a bitwise OR of the following constants:
- S_ISUID
- Verifies that the effective user ID of the client is equal to the user ID specified by the attr->uid member.
- S_ISGID
- Verifies that the effective group ID or one of the supplementary group IDs of the client is equal to the group ID specified by the attr->gid member.
- S_IREAD
- Verifies that the client has READ access to the resource as specified by
attr->mode.
If the client's effective user ID matches that of attr->uid, then the permission check is made against the owner permission field of attr->mode (mask 0700 octal).
If the client's effective user ID doesn't match that of attr->uid, then if the client's effective group ID matches that of attr->gid, or one of the client's supplementary group IDs matches attr->gid, the check is made against the group permission field of attr->mode (mask 0070 octal).
If none of the group fields match, the check is made against the other permission field of attr->mode (mask 0007 octal).
- S_IWRITE
- Same as S_IREAD, except WRITE access is tested.
- S_IEXEC
- Same as S_IREAD, except EXECUTE access is tested. Note that since most resource managers don't actually execute code, the execute access is typically used in its directory sense, i.e., to test for directory accessibility, rather than execute access.
The S_ISUID and S_ISGID flags are mutually exclusive, that is, you may specify at most one of them. In conjunction with the S_ISUID and S_ISGID flags, you may specify zero or more of the S_IREAD, S_IWRITE, and S_IEXEC flags. If no flags are specified, the permission checks are performed for privileged (root) access.
Here's some pseudo-code to try to explain this:
if an ability check was requested using iofunc_client_info_able(),
and the check failed:
return EACCES
if superuser:
return EOK
if S_ISUID and effective user ID == file user ID:
return EOK
if S_ISGID and effective group ID == file group ID, or
a supplemental group ID == file group ID:
return EOK
if S_IREAD or S_IWRITE or S_IEXEC:
if caller's user ID == effective user ID:
if all permissions are set in file's owner mode bits:
return EOK
else:
return EACCES
if ( caller's group ID or supplementary group IDs ) ==
effective group ID:
if all permissions are set in file's group mode bits:
return EOK
else:
return EACCES
if all permissions are set in file's other mode bits:
return EOK
else:
return EACCES
return EPERM
Returns:
- EACCES
- The client doesn't have permissions to do the operation.
- ENOSYS
- NULL was passed for info structure.
- EOK
- Successful completion.
- EPERM
- The group ID or owner ID didn't match.
Classification:
Safety: | |
---|---|
Cancellation point | No |
Signal handler | Yes |
Thread | Yes |