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]

This message is issued when RACF® detects an unauthorized request (a violation) made by a user or job. The user and group that is 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 that is 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 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 that is 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.

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 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/FSEXEC} 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, FSEXEC indicates a profile in the FSEXEC 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. ACCESS ALLOWED (FSEXEC –––) occurs if the user does not have access to the FSEXEC 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 that are defined in the relevant RACF USER and GROUP profiles, because UNIX System Services provides methods by which another identity can be assumed.