Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
ICH408I z/OS Security Server RACF Messages and Codes SA23-2291-00 |
|
ICH408I USER (userid) GROUP (group-name)
NAME (user-name) --or-- JOB (jobname)
STEP (stepname) [SUBMITTER (userid)]
[PRIMARY USER (userid)] [resource-name]
[CL(class-name)] --or-- [VOL(volume-id)]
[FID(file-identifier)] [ID(IPC-identifier)]
--or-- [FROM generic-profile-name (G)] [ACCESS
INTENT(intent) ACCESS ALLOWED(allowed)]
[EFFECTIVE UID (nnnnnnnnnn] [EFFECTIVE GID (nnnnnnnnnn] ExplanationThis message is issued when RACF® detects an unauthorized request (a violation) made by a user or job. The user and group indicated in the first line of the ICH408I message are the execution user ID and group ID under which the job was to run. If the message indicates a job and step instead of a user, group, and name, RACF cannot find a valid ACEE containing user, group, and name information. This can occur for a started task that is not defined in the RACF started procedures table (ICHRIN03), if an entry in the started procedures table has an incorrect RACF group specified, or if the user's ACEE is corrupted. If the submitting user ID is not the same as the execution user ID, the message includes an additional line containing the submitting user ID, group, and node. When the message is reporting an access failure for a delegated resource using a nested ACEE, PRIMARY USER is displayed. A nested ACEE is an ACEE for a client which indicates the identity of the server or daemon that created the work unit. The client user ID is displayed as the primary user. The first line of this message identifies the server or daemon on whose behalf the resource is being accessed. You should permit the daemon to the resource rather than the client. See z/OS Security Server RACF Security Administrator's Guide for information about delegated resources and nested ACEEs. Depending on the resource name, consult the appropriate application documentation for setup requirements. When USER(userid) contains a user ID
in the form of “**nnxxxx”, such as “**01XUSR”, the user ID identifies
an identity context reference, not a RACF user
ID. This value, along with a password substitution value, can be used
to retrieve information about an authenticated user from an identity
cache. See ../com.ibm.zos.v2r1.eima100/eim2a100.htm for
more information about identity cache support. When an identity context
reference is specified on a RACROUTE REQUEST=VERIFY,ENVIR=CREATE request, RACF attempts to resolve the reference
to a RACF-defined user from the identity cache. If RACF cannot resolve the reference, any resulting
ICH408I messages contains the unresolved identity context reference
user value. Possible reasons that the identity context reference cannot
be resolved include:
When the message is reporting an access failure for a z/OS UNIX file, the resource
name is the path name that was specified to the kernel syscall.
It does not exist for the syscalls performed against open files (those
in the "fxxxxx" format such as fchown). The
FID (file identifier) is a unique 32-hex-digit
identifier of the file. It is provided because multiple path names
can be used to access the same file. This identifier allows matching
of accesses to the same file by different names. The z/OS UNIX systems administrator
can use the zfsadm command to query the settings for zFS. See z/OS UNIX System Services Command Reference for
more information about file system settings.
Note: An FID might map
to multiple file names if your zFS aggregate is not enabled for unique
auditids. See z/OS Distributed File Service zFS Administration for
more information about configuration information.
When the message is reporting an access failure for an z/OS UNIX IPC key, the resource name is the IPC key name that was specified to the kernel syscall. It is displayed as a unique 8-hex-digit identifier. The ID (IPC identifier) is a unique decimal identifier of the resource. It is provided as additional information, that might be useful during auditing, although it is dynamically allocated by the kernel. It is a numeric value between 0 and 4294967295. The meaning of the volume serial number shown in the VOL field varies. For a non-VSAM data set, it means the volume on which the data set resides. For a VSAM data set, it means the volume on which the catalog containing the data set entry resides. The phrase FROM generic-profile-name (G),
if included in the message, identifies the generic profile that RACF used to check for access to
the resource.
Note: If
used against a DATASET resource-name,
and the data set is on tape, then the FROM generic-profile-name might
be a TAPEVOL profile, if the TAPEVOL class is active.
For further explanations of this message, check the message line that indicates what request was made. This is typically line 2 or 3. For example, it can be INSUFFICIENT ACCESS AUTHORITY. Find this message line among the explanations that follow for message ICH408I (arranged alphabetically), and read the explanation for that message line. For attempts to use protected resources, the message shows that the access attempted (ACCESS INTENT phrase) and the access permitted by RACF (ACCESS ALLOWED phrase). When the message is reporting an attempt to access an z/OS UNIX file or IPC key, the ACCESS INTENT (intent) is specified as "RWX", representing read, write, or search/execute permission requested. More than one permission can be requested at a time. If a permission is not requested, the letter is replaced by a dash "-". ACCESS ALLOWED (allowed) is specified as "{OWNER/GROUP/OTHER/ACL USER/ACL GROUP/NO/RESTRICTED/FSACCESS} RWX", where OWNER indicates the owner permission bits were used, GROUP indicates the group permission bits were used, OTHER indicates the other permission bits were used, ACL USER indicates that a specific user Access Control List (ACL) entry was used, ACL GROUP indicates a specific group ACL entry (or entries) was used, NO indicates that no permission bits were used, RESTRICTED indicates the OTHER bits were not used for a RESTRICTED user, FSACCESS indicates a profile in the FSACCESS class was used, and "RWX" represents the settings of the permission bits that were checked. ACCESS ALLOWED (NO --X) occurs if a superuser attempts to execute a file that does not have OWNER, GROUP, ACL, or OTHER execute permission. ACCESS ALLOWED (RESTRICTED –––) occurs if a RESTRICTED user only gains file access by way of the OTHER bits, but is forbidden by the RESTRICTED.FILESYS.ACCESS profile in the UNIXPRIV class. ACCESS ALLOWED (FSACCESS –––) occurs if the user does not have access to the FSACCESS profile protecting the file system that contains the resource. Note that while checking for group access, the group permission bits are treated as simply another GID ACL entry, if the process GID, or one of its supplemental GIDs matches the file owner GID. Several group entries might actually be checked, and access is granted if any of them specifies the requested permissions. However, if none of the entries grants the requested access, there is no single entry that defines the access allowed. By convention, the permissions associated with the first relevant group entry encountered are displayed in the message. See the z/OS® UNIX information in z/OS Security Server RACF Security Administrator's Guide for a description of the algorithm used to determine access when an ACL exists for a file or directory. For violations occurring in the UNIX System Services environment, the user's effective UID and effective GID are displayed in the message. These ids were used to determine the user's privilege for the intended operation. Note that they might not always match the ids defined in the relevant RACF USER and GROUP profiles, because UNIX System Services provides methods by which another identity can be assumed. System actionIf the phrase RESOURCE NOT PROTECTED appears
in the message with a warning, RACF allows
the request to continue. If the phrase RESOURCE NOT PROTECTED appears
in the message without a warning, RACF fails
the request.
Note:
Operator responseFollow the security procedures established for your installation. If no such procedures are established, report the complete text of this message to the RACF security administrator. User responseFollow the security procedures established for your installation. If no such procedures are established, report the complete text of this message to the RACF security administrator. Problem determinationDetailed information about the violation
is available in the SMF type 80 record that RACF produces at the same time as this message.
See z/OS Security Server RACF Auditor's Guide
for information about reporting on the contents of the RACF SMF
records.
Note:
Routing code9 and 11 Descriptor code4 This message is routed to the security console. All violations (except LOGON/JOB initiation/initACEE messages, command violations, and z/OS UNIX System Services violations) are issued as write-to-programmer (WTP) messages. Note: A TSO/E
user who is using z/OS UNIX System Services does
not see the ICH408I messages.
|
Copyright IBM Corporation 1990, 2014
|