Special considerations for authority collection

  1. The authority collection support does NOT collect data that is related to interfaces that check special authority. Authority collection data that is related to *ALLOBJ special authority is collected as it affects object level security. Other special authority checks, such as *JOBCTL or *SAVSYS, do not generate authority collection entries. Special authority settings for a specific user profile are easy to check by using the existing security interfaces such as the Display User Profile (DSPUSRPRF) command and related APIs or by querying the QSYS2.USER_INFO view.
  2. Function usage settings (also called application administration) are not collected for the same reason as special authority settings. Function usage settings for a specific user profile are easy to check and are managed by using the Work with Function Usage (WRKFCNUSG) command or by querying the QSYS2.FUNCTION_USAGE view.
  3. The system automatically excludes authority collection data when the IBM i operating system accesses an object and authority is available because of program adopted authority from the operating system. The operating system uses program adopted authority to manage and secure objects and control blocks that it uses. In addition, the operating system uses program adopted authority for situations where it requires access to an object for a specific reason and the current user of the job is not authorized.
  4. The open file (*FILE objects) support for authority collection is for full opens only (no shared or pseudo open is logged). The initial authority collection occurs at file open but the data is not written to the authority collection repository until a hard close on the file is done. Writing the authority collection data to the repository for the file open/close case must be done at close time to accurately log the authority that is required for the application. The open might be done for read/add/update/delete but the application might only read the data.
  5. Authority collection of column permissions for a Db2® table is not supported.
  6. If an authority collection contains information for an object that resides in an Independent Auxiliary Storage Pool (IASP) then that IASP must be available when a query is run against the collection. If the IASP is not available, the information for that object will not be included in the query results.

Special considerations for authority collection for a user

  1. The system automatically excludes certain system libraries and their objects, such as QRCL, QRECOVERY, QSPL, QTEMP, QPTFOBJ1, or QPTFOBJ2 (and the corresponding IASP version of the system libraries), from the authority collection data. Also excluded are authority checks against objects that are not in a library, folder, or directory.
  2. The system automatically excludes IBM i programs and service programs from the authority collection data. Programs or service programs that are *SYSTEM domain or have a program state of *SYSTEM or *INHERIT are excluded from the authority collection. These attributes can be displayed by using the Display Program (DSPPGM) and Display Service Program (DSPSRVPGM) commands.
  3. If the STRAUTCOL command is used to start the authority collection for a user profile and the partition is IPLed, the authority collection continues when a job (post IPL) running under the specified user profile starts.
  4. The system automatically excludes authority collection data for document library objects and file system objects that have been deleted.
  5. IBM i supports a capability that is called profile swap. A profile swap can occur within an active job to swap the current user of a thread from one user to another. When this profile swap occurs, the authority collection of the previous user, for this thread, is no longer active because the current user changed. If the newly swapped user has authority collection active, any authority checks made are now logged under this user’s authority collection repository.
  6. If a user profile with an active authority collection is deleted, the authority collection is automatically ended before the user profile is deleted.
  7. To collect authority information for object types that are only allowed in QSYS (for example, *LIB), specify parameter LIBINF(*ALL) on the STRAUTCOL command. When authority collection includes object type *LIB, library objects that start with QSYS* are automatically excluded from the authority collection data.
  8. When authority collection is started for a user that has an existing authority collection data repository, new authority data is added to the existing information unless parameter DLTCOL(*YES) is specified. New authority collection data can only be added to the existing information if the value specified on the DETAIL parameter matches the value that was specified on the DETAIL parameter when the existing authority information was collected.
Start of change

Special considerations for authority collection for objects

  1. If the STRAUTCOL command is used to start authority collection for objects and the partition is IPLed, the authority collection remains active after the IPL.
  2. The authority collection value cannot be set for QTEMP library or objects in it.
  3. The authority collection value cannot be set for QSYS library or libraries with names that begin with QSYS.
  4. When changing the authority collection value by specifying an object name pattern in the OBJ parameter or by specifying SUBTREE(*ALL) any objects of an unsupported type are ignored.
  5. When authority collection for objects is started and data exists in the authority collection repository for objects, new authority data is added to the existing information unless parameter DLTCOL(*ALL) is specified.
  6. When the operating system is installed, authority collection for objects is ended if it is active.
End of change