IBM i Security

Track Restored IBM i Programs That Adopt Authority with SQL

Use SYSTOOLS.AUDIT_JOURNAL_RP to identify restored IBM i programs and service programs that adopt their owner's authority, validate their current attributes and owners, and build a controlled post-recovery security review.

A restored IBM i program can bring more than executable code back into an environment. When the program is configured with USRPRF(*OWNER), a caller can temporarily use the program owner’s authority while the program runs. SYSTOOLS.AUDIT_JOURNAL_RP identifies those adopting programs at restore time.

The service formats audit entry type:

RP

which represents:

Restoring Programs that Adopt Authority

This matters after:

• disaster-recovery exercises
• production recovery
• application migrations
• environment refreshes
• vendor software restores
• save-file deployments
• program or service-program recovery

The security questions are:

Which adopting program was restored?
Who owns it?
How powerful is that owner?
Who can call the program?
Does the program still need adopted authority?
Did the target environment expect this object?
Was it reviewed before the recovery was approved?

What adopted authority means

IBM i supports two related—but different—authority attributes.

USRPRF(*OWNER)

The program adopts the authority of its owner while it runs.

The caller’s authority and the program owner’s authority can both participate in authority checks.

USEADPAUT(*YES)

The program can use adopted authority passed from earlier programs in the call stack.

A program can therefore:

• adopt its own owner’s authority
• inherit adopted authority from a previous call level
• do both
• do neither

The RP entry is focused on restored programs that adopt the owner’s authority.

Do not treat USRPRF(*OWNER) and USEADPAUT(*YES) as interchangeable.

Query recent RP entries

SELECT *
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RP(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 1 DAY
    )
)
ORDER BY
    ENTRY_TIMESTAMP DESC;

The service returns common audit-journal columns followed by RP-specific fields.

RP-specific columns

Important columns include:

ENTRY_TYPE
ENTRY_TYPE_DETAIL
OBJECT_LIBRARY
OBJECT_NAME
OBJECT_TYPE
OBJECT_OWNER
OBJECT_ASP_NAME
OBJECT_ASP_NUMBER
PATH_NAME
PATH_NAME_INDICATOR
RELATIVE_DIRECTORY_FILE_ID
IFS_OBJECT_NAME
OBJECT_FILE_ID
PARENT_FILE_ID

For ENTRY_TYPE:

A

means a program that adopts its owner’s authority was restored.

Review restored adopting programs

SELECT
    ENTRY_TIMESTAMP,
    USER_NAME AS RESTORE_RUN_BY,
    QUALIFIED_JOB_NAME,
    PROGRAM_LIBRARY,
    PROGRAM_NAME,
    OBJECT_LIBRARY,
    OBJECT_NAME,
    OBJECT_TYPE,
    OBJECT_OWNER,
    OBJECT_ASP_NAME,
    OBJECT_ASP_NUMBER,
    RECEIVER_LIBRARY,
    RECEIVER_NAME,
    SEQUENCE_NUMBER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RP(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 7 DAYS
    )
)
ORDER BY
    ENTRY_TIMESTAMP DESC,
    SEQUENCE_NUMBER DESC;

This identifies:

• the restored object
• its owner at restore time
• the job and effective profile performing the restore
• the ASP location
• the original audit receiver and sequence

Find programs owned by sensitive profiles

Maintain a controlled list:

CREATE TABLE SECURITY.SENSITIVE_PROFILE
(
    USER_PROFILE       VARCHAR(10) PRIMARY KEY,
    RISK_CLASS         VARCHAR(20) NOT NULL,
    BUSINESS_OWNER     VARCHAR(128),
    TECHNICAL_OWNER    VARCHAR(128),
    REVIEW_REQUIRED    CHAR(1) NOT NULL
);

Then:

SELECT
    R.ENTRY_TIMESTAMP,
    R.USER_NAME AS RESTORE_RUN_BY,
    R.OBJECT_LIBRARY,
    R.OBJECT_NAME,
    R.OBJECT_TYPE,
    R.OBJECT_OWNER,
    P.RISK_CLASS,
    P.BUSINESS_OWNER,
    P.TECHNICAL_OWNER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RP(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
) AS R
JOIN SECURITY.SENSITIVE_PROFILE AS P
  ON P.USER_PROFILE = R.OBJECT_OWNER
WHERE P.REVIEW_REQUIRED = 'Y'
ORDER BY
    R.ENTRY_TIMESTAMP DESC;

Profiles deserving close review can include:

• profiles with *ALLOBJ
• application-owner profiles
• deployment profiles
• database-owner profiles
• profiles with access to regulated information
• profiles controlling payment, payroll, or identity data
• profiles whose authority differs between environments

A profile does not need special authority to be security-sensitive.

Why the owner matters

A program with:

USRPRF(*OWNER)

adopts the owner’s authority.

Changing the owner can therefore change the effective authority available while the program runs.

A restore can reintroduce:

• a powerful source-system owner
• an owner that should not exist in the target environment
• a vendor profile with broad authority
• an application profile whose authorities were restored differently
• a program whose owner changed after the save

The RP entry is evidence that the restored program adopts authority and records the owner associated with it.

Compare the audit entry with current program attributes

QSYS2.PROGRAM_INFO exposes the current program or service-program attributes.

SELECT
    R.ENTRY_TIMESTAMP,
    R.OBJECT_LIBRARY,
    R.OBJECT_NAME,
    R.OBJECT_TYPE,
    R.OBJECT_OWNER AS OWNER_AT_RESTORE,
    P.PROGRAM_OWNER AS CURRENT_OWNER,
    P.USER_PROFILE,
    P.USE_ADOPTED_AUTHORITY,
    P.PROGRAM_TYPE,
    P.TEXT_DESCRIPTION
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RP(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
) AS R
LEFT JOIN QSYS2.PROGRAM_INFO AS P
  ON P.PROGRAM_LIBRARY = R.OBJECT_LIBRARY
 AND P.PROGRAM_NAME = R.OBJECT_NAME
WHERE R.OBJECT_TYPE IN ('*PGM', '*SRVPGM')
ORDER BY
    R.ENTRY_TIMESTAMP DESC;

For a program that still adopts its owner, expect:

USER_PROFILE = '*OWNER'

USE_ADOPTED_AUTHORITY tells you whether it can also use adopted authority from previous programs in the stack.

A mismatch can mean:

• the program was changed after restore
• ownership was transferred
• the object was replaced
• the object no longer exists
• a different object type requires another validation method
• the caller lacks authority to see the object

Find owner changes after restore

WITH RESTORED AS
(
    SELECT
        ENTRY_TIMESTAMP,
        OBJECT_LIBRARY,
        OBJECT_NAME,
        OBJECT_TYPE,
        OBJECT_OWNER
    FROM TABLE(
        SYSTOOLS.AUDIT_JOURNAL_RP(
            STARTING_TIMESTAMP =>
                CURRENT TIMESTAMP - 30 DAYS
        )
    )
)
SELECT
    R.ENTRY_TIMESTAMP,
    R.OBJECT_LIBRARY,
    R.OBJECT_NAME,
    R.OBJECT_TYPE,
    R.OBJECT_OWNER AS OWNER_AT_RESTORE,
    P.PROGRAM_OWNER AS CURRENT_OWNER,
    CASE
        WHEN P.PROGRAM_NAME IS NULL
          THEN 'NOT FOUND'
        WHEN P.PROGRAM_OWNER <> R.OBJECT_OWNER
          THEN 'OWNER CHANGED'
        ELSE 'OWNER MATCHES'
    END AS OWNER_STATUS
FROM RESTORED AS R
LEFT JOIN QSYS2.PROGRAM_INFO AS P
  ON P.PROGRAM_LIBRARY = R.OBJECT_LIBRARY
 AND P.PROGRAM_NAME = R.OBJECT_NAME
ORDER BY
    R.ENTRY_TIMESTAMP DESC;

An ownership change is not automatically unauthorized.

It should have an approved reason because ownership affects adopted authority.

Find restored programs no longer configured to adopt

SELECT
    R.ENTRY_TIMESTAMP,
    R.OBJECT_LIBRARY,
    R.OBJECT_NAME,
    R.OBJECT_OWNER,
    P.USER_PROFILE,
    P.USE_ADOPTED_AUTHORITY
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RP(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
) AS R
LEFT JOIN QSYS2.PROGRAM_INFO AS P
  ON P.PROGRAM_LIBRARY = R.OBJECT_LIBRARY
 AND P.PROGRAM_NAME = R.OBJECT_NAME
WHERE P.PROGRAM_NAME IS NOT NULL
  AND P.USER_PROFILE <> '*OWNER'
ORDER BY
    R.ENTRY_TIMESTAMP DESC;

This can indicate a deliberate hardening step after restore.

Correlate it with:

• deployment records
• change tickets
• object-change audit entries
• owner-transfer activity
• application testing

Find programs that both adopt and inherit authority

SELECT
    PROGRAM_LIBRARY,
    PROGRAM_NAME,
    PROGRAM_TYPE,
    PROGRAM_OWNER,
    USER_PROFILE,
    USE_ADOPTED_AUTHORITY,
    TEXT_DESCRIPTION
FROM QSYS2.PROGRAM_INFO
WHERE USER_PROFILE = '*OWNER'
  AND USE_ADOPTED_AUTHORITY = '*YES'
ORDER BY
    PROGRAM_OWNER,
    PROGRAM_LIBRARY,
    PROGRAM_NAME;

These programs deserve additional review because they can adopt their own owner’s authority and use authority passed from previous programs in the call stack.

That does not make them inherently unsafe.

It increases the importance of:

• call-path review
• source-code review
• command-line prevention
• parameter validation
• object authority
• ownership policy
• least privilege

Review programs owned by *ALLOBJ profiles

The most direct high-risk scenario is an adopting program owned by a profile with *ALLOBJ.

A conceptual query is:

SELECT
    R.ENTRY_TIMESTAMP,
    R.OBJECT_LIBRARY,
    R.OBJECT_NAME,
    R.OBJECT_TYPE,
    R.OBJECT_OWNER,
    U.SPECIAL_AUTHORITIES
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RP(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
) AS R
JOIN QSYS2.USER_INFO AS U
  ON U.AUTHORIZATION_NAME = R.OBJECT_OWNER
WHERE U.SPECIAL_AUTHORITIES LIKE '%*ALLOBJ%'
ORDER BY
    R.ENTRY_TIMESTAMP DESC;

Confirm the exact USER_INFO special-authority column and returned format on the installed release before production use.

IBM recommends identifying programs that adopt the authority of *ALLOBJ profiles and reviewing who can use those programs.

Review who can call the program

An adopting program is most dangerous when broad populations can execute it.

Use QSYS2.OBJECT_PRIVILEGES for current QSYS object authority:

SELECT
    AUTHORIZATION_NAME,
    OBJECT_AUTHORITY,
    AUTHORIZATION_LIST,
    OBJECT_OWNER,
    PRIMARY_GROUP
FROM QSYS2.OBJECT_PRIVILEGES
WHERE SYSTEM_OBJECT_SCHEMA = 'PAYLIB'
  AND SYSTEM_OBJECT_NAME = 'PAYRUN'
  AND OBJECT_TYPE = '*PGM'
ORDER BY
    AUTHORIZATION_NAME;

Review:

*PUBLIC authority
Group authority
Authorization-list access
Private *USE or *ALL authority
Owner authority
Primary-group authority

A program can be correctly designed yet exposed to too many callers.

Review the code path—not just the attributes

Adopted authority is a controlled privilege boundary.

The program should not let callers escape the intended function.

Review for:

• command-line access
• uncontrolled command strings
• QCMDEXC or command APIs using caller input
• dynamic SQL built from untrusted input
• arbitrary object names
• unrestricted file or library parameters
• user-controlled program calls
• shell or PASE command execution
• debug or service interfaces
• insecure error handling
• calls to programs that inherit adopted authority

The program should perform a narrow business function, not act as a general privileged executor.

Understand the call stack

Adopted authority can flow through a call stack.

USEADPAUT(*YES) controls whether a program can use adopted authority from previous call levels.

IBM warns that allowing later programs to inherit adopted authority can create a Trojan-horse opportunity if an untrusted program is called while powerful adopted authority remains active.

Review:

Who calls the restored program?
What does it call?
Which objects use USRPRF(*OWNER)?
Which called programs have USEADPAUT(*YES)?
Where is adopted authority intentionally stopped?

Review QUSEADPAUT

The system value:

QUSEADPAUT

controls who can create, change, or update programs and service programs with:

USEADPAUT(*YES)

The default value is:

*NONE

which allows all users with the otherwise-required object authority to work with this attribute.

A more restrictive design can name an authorization list.

Users need at least *USE authority to that list to create or change objects to use adopted authority from previous call levels.

This control affects USEADPAUT, not whether an existing program uses USRPRF(*OWNER).

Review both attributes separately.

Correlate RP with AP activity

RP tells you that an adopting program was restored.

AP records adopted-authority activity, including start, end, or use during program activation.

A useful review connects:

RP   Restored adopting program
AP   Adopted authority later used

This can answer:

Was the restored program actually invoked?
Whose authority was adopted?
Which job used it?
Was use expected after recovery?

Use:

SYSTOOLS.AUDIT_JOURNAL_AP

for AP entries when the required audit configuration and receivers are available.

RP identifies potential capability.

AP provides evidence of adopted-authority activity.

Build an expected-program policy

CREATE TABLE SECURITY.ADOPTING_PROGRAM_POLICY
(
    ENVIRONMENT_NAME       VARCHAR(20) NOT NULL,
    PROGRAM_LIBRARY        VARCHAR(10) NOT NULL,
    PROGRAM_NAME           VARCHAR(10) NOT NULL,
    PROGRAM_TYPE           VARCHAR(10) NOT NULL,
    EXPECTED_OWNER         VARCHAR(10) NOT NULL,
    EXPECTED_USER_PROFILE  VARCHAR(10) NOT NULL,
    EXPECTED_USE_ADOPTED   VARCHAR(4) NOT NULL,
    BUSINESS_OWNER         VARCHAR(128),
    REVIEW_PRIORITY        INTEGER NOT NULL,
    PRIMARY KEY
    (
        ENVIRONMENT_NAME,
        PROGRAM_LIBRARY,
        PROGRAM_NAME,
        PROGRAM_TYPE
    )
);

Compare restored evidence with policy:

SELECT
    R.ENTRY_TIMESTAMP,
    R.OBJECT_LIBRARY,
    R.OBJECT_NAME,
    R.OBJECT_TYPE,
    R.OBJECT_OWNER AS OWNER_AT_RESTORE,
    P.EXPECTED_OWNER,
    P.EXPECTED_USER_PROFILE,
    P.EXPECTED_USE_ADOPTED,
    CASE
        WHEN P.PROGRAM_NAME IS NULL
          THEN 'NO POLICY'
        WHEN R.OBJECT_OWNER <> P.EXPECTED_OWNER
          THEN 'OWNER MISMATCH'
        ELSE 'REVIEW CURRENT ATTRIBUTES'
    END AS POLICY_STATUS
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RP(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 7 DAYS
    )
) AS R
LEFT JOIN SECURITY.ADOPTING_PROGRAM_POLICY AS P
  ON P.ENVIRONMENT_NAME = 'PROD'
 AND P.PROGRAM_LIBRARY = R.OBJECT_LIBRARY
 AND P.PROGRAM_NAME = R.OBJECT_NAME
 AND P.PROGRAM_TYPE = R.OBJECT_TYPE
ORDER BY
    P.REVIEW_PRIORITY DESC,
    R.ENTRY_TIMESTAMP DESC;

Preserve the evidence

CREATE TABLE RECOVERY.RP_AUDIT_EVIDENCE
(
    RECOVERY_ID          VARCHAR(40) NOT NULL,
    SOURCE_SYSTEM        VARCHAR(8) NOT NULL,
    RECEIVER_LIBRARY     VARCHAR(10) NOT NULL,
    RECEIVER_NAME        VARCHAR(10) NOT NULL,
    SEQUENCE_NUMBER      DECIMAL(21, 0) NOT NULL,
    ENTRY_TIMESTAMP      TIMESTAMP NOT NULL,
    RESTORE_RUN_BY       VARCHAR(10),
    QUALIFIED_JOB_NAME   VARCHAR(28),
    OBJECT_LIBRARY       VARCHAR(10),
    OBJECT_NAME          VARCHAR(10),
    OBJECT_TYPE          VARCHAR(10),
    OBJECT_OWNER         VARCHAR(10),
    OBJECT_ASP_NAME      VARCHAR(10),
    OBJECT_ASP_NUMBER    INTEGER,
    PATH_NAME            DBCLOB(16M) CCSID 1200,
    REVIEW_STATUS        VARCHAR(24) NOT NULL,
    ISSUE_REFERENCE      VARCHAR(128),
    REVIEW_NOTES         VARCHAR(2048),
    PRIMARY KEY
    (
        SOURCE_SYSTEM,
        RECEIVER_LIBRARY,
        RECEIVER_NAME,
        SEQUENCE_NUMBER
    )
);

Useful statuses include:

NEW
EXPECTED
OWNER REVIEW
HIGH-AUTHORITY OWNER
BROAD CALL AUTHORITY
CODE REVIEW REQUIRED
HARDENED
APPROVED EXCEPTION

Use bounded collection

A scheduled collector should preserve:

Journal
Receiver library
Receiver name
Sequence number
Entry timestamp
Recovery ID
Collection status

Read a bounded source range, store the evidence, commit it, then advance the checkpoint.

Do not rely only on sequence number because journal sequences can be reset.

Auditing must already be active

The RP service reads:

QSYS/QAUDJRN

The relevant save-and-restore auditing must have been active when the program was restored, and the receiver must still be available.

Review:

QAUDCTL
QAUDLVL
QAUDLVL2
*SAVRST coverage
receiver retention
audit failure handling

No query can reconstruct an event that was not audited.

Required authority

The reporting profile needs appropriate authority to:

QSYS/QAUDJRN
The journal library
Every requested receiver
Each receiver library

Current-state checks through PROGRAM_INFO, USER_INFO, and OBJECT_PRIVILEGES have their own authority requirements.

Use a dedicated audit-reporting profile rather than granting broad authority for convenience.

Do not automatically remove adopted authority

A restored adopting program may be an intentional application-security control.

Changing:

USRPRF(*OWNER) to USRPRF(*USER)

without understanding the application can break:

• protected database access
• batch processing
• interfaces
• payment processing
• administrative workflows
• security separation intentionally implemented through a trusted program

The safe workflow is:

Detect
Validate owner
Review current attributes
Review callers
Review code
Assess least privilege
Test in a controlled environment
Approve the change
Revalidate application behavior
Preserve evidence

Recovery sign-off checklist

Before closing a recovery:

Collect every RP entry in the recovery window
Review the owner of every adopting object
Identify owners with powerful authority
Compare current USRPRF and USEADPAUT attributes
Review who can execute each program
Inspect sensitive call paths
Correlate actual use through AP entries
Compare with the target environment policy
Test critical business functions
Preserve receiver and sequence evidence
Obtain security-owner approval

Service availability

IBM added SYSTOOLS.AUDIT_JOURNAL_RP in the November 2025 IBM i services update.

IBM documents these minimum Db2 Group PTF levels:

IBM i 7.6 — SF99960 Level 2
IBM i 7.5 — SF99950 Level 11

The RP helper function is not listed for IBM i 7.4 in the current audit-journal service update matrix.

Final takeaway

A restored program can reintroduce a privilege boundary into the target environment.

SYSTOOLS.AUDIT_JOURNAL_RP identifies:

The restored adopting program
Its library and object type
Its owner
Its ASP
The restore job and effective user
The audit receiver and sequence

Use that evidence to answer the questions the restore command cannot:

Is the owner appropriate?
Is the owner too powerful?
Who can call the program?
Does the code restrict callers to the intended function?
Can adopted authority flow further down the call stack?
Does the target environment approve this design?

Restoring an adopting program may be operationally necessary.

Restoring it without reviewing the privilege path is not security validation.