Adopted Authority

Questions


How does adopted authority work?
How can a program be changed to use adopted authority?
How can I determine if adopted authority is being used?

Answers

Adopted Authority allows a user to acquire authority to objects beyond what is granted by *PUBLIC and private authorities. As an example, suppose a user should normally be restricted from payroll files, but to perform his job, the user must be able to run a payroll report. Adopted authority allows the user to acquire enough authority to read the file for the purpose of the payroll report without granting the user any authority to the file outside of the program that runs the report.

Adopted Authority adds the authorities of another user to those of the user running the program. In the example below, assume a program called PAYLIST prints the payroll report. PAYLIST resides in PAYLIB.

Before granting adopted authority to PAYLIST, you must determine what authorities it already has. On an operating system command line, type the following:

DSPPGM PAYLIB/PAYLIST

Press the Enter key. This shows the following (or similar):

Program  . . . . . . . :   PAYLIST        Library  . . . . . . . :   PAYLIB
Owner  . . . . . . . . :   JONES                                          
Program attribute  . . :   RPG                                            
                                                                         
Program creation information:                                              
 Program creation date/time . . . . . . . . . . . :  12/13/96  14:53:39  
 Type of program  . . . . . . . . . . . . . . . . :  OPM                
 Source file  . . . . . . . . . . . . . . . . . . :  RPGSRC              
   Library  . . . . . . . . . . . . . . . . . . . :    PAYTEST          
 Source member  . . . . . . . . . . . . . . . . . :  PAYLIST              
 Source file change date/time . . . . . . . . . . :  12/13/96  14:53:28  
 Observable information . . . . . . . . . . . . . :  *ALL                
 User profile . . . . . . . . . . . . . . . . . . :  *USER              
 Use adopted authority  . . . . . . . . . . . . . :  *NO                
  Fix decimal data . . . . . . . . . . . . . . . . :  *NO

The fields of immediate interest to us are OWNER, User profile, and Use adopted authority.

User profile . . . . : *USER means to use the authorities of the user, that is, the User Profile running the program. We do not adopt any authorities from the Owner of the program.

If User profile said *OWNER, the program runs combining the authorities of the Owner of the program with those of the User Profile running the program. The owner of the program is shown in the field at the top, Owner. In this case, the owner of the program is the User profile called JONES. If a user with a user profile of SMITH ran the program, the program combines all of SMITH's private authorities with those of JONES. If SMITH does not have sufficient authority to the payroll files to run the program, but JONES does, the program runs.

Using adopted authority means to adopt authority from the prior program in the call stack. It does not mean adopt authority from the owner of the program. Suppose program A runs with USRPRF(*OWNER), and program A calls program B. If program B has USEADPAUT(*YES) and USRPRF(*USER), then the authorities granted to program A through adopted authority flow to program B, even though program B adopts no authorities from the program owner. It is possible that program B has USEADPAUT(*YES) and USRPRF(*OWNER). In that case, authority would be combined from the user running the programs, from the owner of program A, and the owner of program B.

If a program presently does not run with adopted authority but you wish it to do so, you can use the Change Program (CHGPGM) command. The following examples of CHGPGM commands enable a program to adopt authority:

CHGPGM PGM(PAYLIB/PAYLIST) USRPRF(*OWNER)

CHGPGM PGM(PAYLIB/PAYLIST) USEADPAUT(*YES)

CHGPGM PGM(PAYLIB/PAYLIST) USRPRF(*OWNER) USEADPAUT(*YES)

Suppose a user has too much authority? A check of private authorities, Group Profile, Authorization Lists, and so on does not explain why the user is able to do all of the tasks being done. Look at the program stack.

Sign on as that user and issue a DSPJOB or WRKACTJOB command. Find the job in question, type 5 next to it, and press the Enter key.

In either case, a menu is shown. Select Option 11, Display call stack, if active.

You are shown something similar to the following:
 

Request     Program or                                               Opt   Level       Procedure        Library       Statement    Instruction                  QCMD             QSYS            0368                   PAYPGM           PAYLIB          0466                              QUICMENU         QSYS            00C1           1          QUIMNDRV         QSYS            0457           2          QUIMGFLW         QSYS            0486           3          QUICMD           QSYS            03E5

Write down the programs in the stack. Starting at the bottom, issue a DSPPGM command on each program. In this example, which is based on numerous actual cases, assume that QUICMD, QUIMGFLW, QUIMNDRV, and QUICMENU all have USEADPAUT(*YES), while PAYPGM has USRPRF(*OWNER). The owner of PAYPGM was QSECOFR. QSECOFR's authority flows down the stack giving the user the same All Object authority as QSECOFR has. This enabled the user to touch any object in the system.

Note: Adopted authority is not supported by the Integrated File System.

Also, if the program running under adopted authority is interrupted, the use of adopted authority is suspended.

The following functions do not use adopted authority:
o System request
o Attention key (If a Transfer to Group Job (TFRGRPJOB) command is running, adopted authority is not passed to the group job.)
o Break-message-handling program
o Debug functions

This is documented in the Security Reference manual in Chapter 5, Resource Security under the section Objects that adopt the owner's authority.