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.
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.
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.
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.
Authority collection of column permissions for a Db2® table is not supported.
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
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.
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.
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.
The system automatically excludes authority collection data for document library objects and file system
objects that have been deleted.
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
If a user profile with an active authority collection is deleted, the authority collection is automatically
ended before the user profile is deleted.
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.
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.
Special considerations for authority collection for objects
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.
The authority collection value cannot be set for QTEMP library or objects in it.
The authority collection value cannot be set for QSYS library or libraries with names that begin with QSYS.
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.
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.
When the operating system is installed, authority collection for objects is ended if it is active.