II12593: EXPLANATION OF ICH408I ... CL(DIRSRCH) INSUFFICIENT AUTHORITY TO LOOKUP, AND MEANING OF 'LOOKUP' PERMISSION

APAR status

• Closed as canceled.

Error description

• A message like:
  ICH408I USER(MYUSER  ) GROUP(MYGROUP ) NAME(Me
    /u/myuser/path  CL(DIRSRCH ) FID(01C7C3E6E5D4E400011E000000000
    INSUFFICIENT AUTHORITY TO LOOKUP
    ACCESS INTENT(--X)  ACCESS ALLOWED(GROUP ---)
  .
  This message indicates that the user does not have LOOKUP
  permission to '/u/mtuser/path'.
  .
  There are four kinds of 'permissions' encoded by the file
  permission bits:
  r Read permission- Are you allowed to read the file/directory?
  w Write permission- Are you allowed to write to the file/directo
  x Execute permission- Are you allowed to execute the file?
  x Lookup permission- Are you allowed to traverse the directory?
  .
  That last one is the one we are talking about. Notice that the
  same bit which encodes execute permision for a file, encodes
  lookup for a directory. To understand why this bit is important
  consider the following:
  Many users do not want to allow other users to read, or write
  any information contained in their home directories, so
  myuser might issue the command:
  chmod 700 /u/myuser
  preventing anyone else from having access. Let us say that the
  user also creates a directory called /u/myuser/public which
  contains information the user wants to share. If read/write were
  the only permissions, then the only way to grant another user
  access to the public directory would be to grant the same access
  to the /u/myuser directory! That unnecessarily exposes files by
  default to any user on the system.
  Lookup permission is an alternative. If myuser issues:
  chmod a+x /u/myuser
  chmod a+r /u/myuser/public
  then every user on the system will be able to read myuser's
  public directory, but will not even be able to list(ls)
  /u/myuser !
  .
  There is just one catch: You do not know from the message which
  directory the user has been denied access to... it could
  be any directory in the path:
  / or /u or /u/myuser or /u/myuser/path
  only by process of elimination can you tell!
  Also, be especially careful when 'path' is a symbolic link!
  Symbolic links _always_ have '777' permission set, so you must
  make sure that you examine the permissions of the actual file/
  directory, not the link which is pointing to it. This applies
  equally to every directory in the entire path... The root
  directory _can_ be a symbolic link!
  

Local fix

• Examples:
  There are two basic approaches to correcting the permissions
  when access is desired.
  1) Verify that that every directory contained in the path
  issued by the DIRSRCH has the execute permission bit set.
  2) Use the File ID (FID) printed in the message to determine the
  search for the exact file which needs to have permission granted
  .
  -------
  Approach #1:
  Examine the path printed in the message. For every intermediate
  directory, including the root, issue the command:
  ls -alLd directory-name
  If the path were: /a/b/c the commands
  ls -alLd /
  ls -alLd /a
  ls -alLd /a/b
  ls -alLd /a/b/c
  should be issued.
  Verify that the execute bits are set by examining the output
  of those commands. Correct if necessary.
  -------
  Approach #2:
  Obtain a tool which will search the file system for a particular
  File ID. One such tool is auditid which can be obtained from
  www-1.ibm.com/servers/eserver/zseries/zos/unix/bpxa1ty2.html
  tml the tool to discover which file is indicated by the FID
  contained in the message. List the file to verify that the
  FID corresponds to the file found; It is that file which
  requires the execute bit to be set. >>directories are files!<<
  .
  chmod +x filename
  Note: After granting this permission, another ICH408I may be
  generated, which although similar, differs in FID.
  -------
  FAQ:
  Q1) I followed Approach #1, and I still get the message, what
  should I do?
  A1) Double check. Cut-and-paste all the input/output to a
  file, so that it is al in one place. Examine carefully, have
  you followed all symbolic links? Did you list out the root
  directory?
  Q2) Symbolic what?
  A2) links. issue a 'man ln' to find out about them. If you see
  a file with '777' in the permission bits, it may be a symbolic
  link.
  Q3) I just created all these directories, what is the default
  permission bit setting?
  A3) It depends. read the man page for mkdir, or the utility you
  used.
  Q4) I found an APAR ow46174, does it apply to me?
  A4) Are you using SUPERUSER.FILESYS, for this user? (UNIXPRIV)
  Q5) I feel that this message is being issued in error, and
  I am about to call the service center, what documentation should
  I collect?
  A5) YOu should have the output from all the ls commands from
  Approach #1. Also, list the user(including OMVS information).
  List the users default group(including OMVS info), list the
  group mentioned in the filename. Also, verify that one of the
  files(directories) listed out has the FID in the message.
  Ensure that lookup permission has ben granted to that file.
  Also, double-check the verification by using both approaches.
  
  KEYWORDS:
  RACF ICH408I FTP TCP/IP ROOT ACCESS EXECUTE READ WRITE
  OE HFS 5752XXH00 5695SCPX1
  

Problem summary

Problem conclusion

Temporary fix

Comments

• closing
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels