Objects that adopt the owner's authority

You can assign adopted authority to a user program to allow the user to change a customer file.

Sometimes a user needs different authorities to an object or an application, depending on the situation. For example, a user might be allowed to change the information in a customer file when using application programs providing that function. However, the same user should be allowed to view, but not change, customer information when using a decision support tool, such as SQL.

A solution to this situation is to 1) give the user *USE authority to customer information to allow querying the files and 2) use adopted authority in the customer maintenance programs to allow the user to change the files.

When an object uses the owner's authority, this is called adopted authority. Objects of type *PGM, *SRVPGM, and *SQLPKG can adopt authority.

When you create a program, you specify a user profile (USRPRF) parameter on the CRTxxxPGM command. This parameter determines whether the program uses the authority of the owner of the program in addition to the authority of the user running the program.

Consult the Limit the use of adopted authority topic concerning security considerations and adopted authority when using SQL packages.

The following description applies to adopted authority:

• Adopted authority is added to any other authority found for the user.
• Adopted authority is checked only if the authority that the user, the user's group, or the public has to an object is not adequate for the requested operation.
• The special authorities (such as *ALLOBJ) in the owner's profile are used.
• If the owner profile is a member of a group profile, the group's authority is not used for adopted authority.
• Public authority is not used for adopted authority. For example, USER1 runs the program LSTCUST, which requires *USE authority to the CUSTMST file:
  • Public authority to the CUSTMST file is *USE.
  • USER1's authority is *EXCLUDE.
  • USER2 owns the LSTCUST program, which adopts owner authority.
  • USER2 does not own the CUSTMST file and has no private authority to it.
  • Although public authority is sufficient to give USER2 access to the CUSTMST file, USER1 does not get access. Owner authority, primary group authority, and private authority are used for adopted authority.
  • Only the authority is adopted. No other user profile attributes are adopted. For example, the limited capabilities attributes are not adopted.
• Adopted authority is active as long as the program using adopted authority remains in the call stack. For example, assume that PGMA uses adopted authority:
  • If PGMA starts PGMB using the CALL command, these are the call stacks before and after the CALL command:

    Table 1. Adopted authority and the CALL command

    Call stack before CALL command:	Call stack after CALL command:
    QCMD • • • PGMA	QCMD • • • PGMA PGMB

    Because PGMA remains in the call stack after PGMB is called, PGMB uses the adopted authority of PGMA. (The use adopted authority (USEADPAUT) parameter can override this. See Programs that ignore adopted authority for more information about the USEADPAUT parameter.)

  • If PGMA starts PGMB using the Transfer Control (TFRCTL) command, the call stacks look like this:

    Table 2. Adopted authority and the TFRCTL command

    Call stack before TFRCTL command:	Call stack after TFRCTL command:
    QCMD • • • PGMA	QCMD • • • PGMB

    PGMB does not use the adopted authority of PGMA, because PGMA is no longer in the call stack.

• If the program running under adopted authority is interrupted, the use of adopted authority is suspended. The following functions do not use adopted authority:
  • System request
  • Attention key (If a Transfer to Group Job (TFRGRPJOB) command is running, adopted authority is not passed to the group job.)
  • Break-message-handling program
  • Debug functions
  Note: Adopted authority is immediately interrupted by the attention key or a group job request. The user must have authority to run the attention-key-handling program or the group job initial program, or the attempt fails.

  For example, USERA runs the program PGM1, which adopts the authority of USERB. PGM1 uses the SETATNPGM command and specifies PGM2. USERB has *USE authority to PGM2. USERA has *EXCLUDE authority to PGM2. The SETATNPGM function is successful because it is run using adopted authority. USERA receives an authority error when attempting to use the attention key because USERB's authority is no longer active.

• If a program that uses adopted authority submits a job, that submitted job does not have the adopted authority of the submitting program.
• When a trigger program or exit point program is called, adopted authority from previous programs in the call stack will not be used as a source of authority for the trigger program or exit point program.
• Adopted authority is not used by the integrated file systems, including the "root" (/), QOpenSys, QDLS, and user-defined file systems.
• The program adopt function is not used when you use the Change Job (CHGJOB) command to change the output queue for a job. The user profile making the change must have authority to the new output queue.
• Any objects created, including spooled files that might contain confidential data, are owned by the user of the program or by the user's group profile, not by the owner of the program.
• Adopted authority can be specified either on the command that creates the program (CRTxxxPGM) or on the Change Program (CHGPGM) or Change Service Program (CHGSRVPGM) command.
• If a program is created using REPLACE(*YES) on the CRTxxxPGM command, the new copy of the program has the same USRPRF, USEADPAUT, and AUT values as the replaced program. The USRPRF and AUT parameters specified on the CRTxxxPGM parameter are ignored.
• Only the owner of the program can specify REPLACE(*YES) on the CRTxxxPGM command when USRPRF(*OWNER) is specified on the original program.
• Only a user who owns the program or has *ALLOBJ and *SECADM special authorities can change the value of the USRPRF parameter.
• You must be signed on as a user with *ALLOBJ and *SECADM special authorities to transfer ownership of an object that adopts authority.
• If someone other than the program's owner or a user with *ALLOBJ and *SECADM special authorities restores a program that adopts authority, all private and public authorities to the program are revoked to prevent a possible security exposure.

The Display Program (DSPPGM) and Display Service Program (DSPSRVPGM) commands show whether a program adopts authority (User profile prompt) and whether it uses adopted authority from previous programs in the call stack (Use adopted authority prompt). The Display Program Adopt (DSPPGMADP) command shows all the objects that adopt the authority of a specific user profile. The Print Adopting Objects (PRTADPOBJ) command provides a report with more information about objects that adopt authority. This command also provides an option to print a report for objects that have been changed since the last time the command was run.

Flowchart 8: How adopted authority is checked provides more information about adopted authority. The topic Using adopted authority in menu design shows an example of how to use adopted authority in an application.

Adopted authority and bound programs:

An ILE* program (*PGM) is an object that contains one or more modules. It is created by an ILE* compiler. An ILE program can be bound to one or more service programs (*SRVPGM).

To activate an ILE program successfully, the user must have *EXECUTE authority to the ILE program and to all service programs to which it is bound. If an ILE program uses adopted authority from a program higher in the program call stack, that adopted authority is used to check authority to all service programs to which the ILE program is bound. If the ILE program adopts authority, the adopted authority will not be checked when the system checks the user's authority to the service programs at program activation time.