On a program object, there are two parameters that affect adopted authority (use the CHGPGM and DSPPGM commands to see, or affect, these parameters). They are the USRPRF and USEADPAUT parameters--and they don't work the way you might think at first.

The USRPRF parameter controls whose authority the program uses when it is executed. It can contain one of two values: *USER or *OWNER. *USER indicates that the program, when executed, will run under the authority of the end user who called it. *USER is the default value for newly created programs and is also the more common usage. *OWNER indicates that the program will adopt the authority of the user profile that owns the program object. If you use *OWNER, when the program executes, it runs with the combined authority of the original end user plus the authority of the program object's owner--sort of a two-fer. In a scenario where program PROGA calls PROGB, and PROGB calls PROGC, and all of these programs are set to USRPRF(*OWNER) and have separate owners, PROGC will run under the combined authority of the original user, plus the individual owners of PROGA, PROGB, and PROGC.

This is what is traditionally known as "adopted authority," and it is very useful for providing users with an elevated level of authority for a short period of time or with a limited amount of function.

The second parameter is more confusing, and the text surrounding this parameter is squarely to blame. The Use Adopted Authority (USEADPAUT) parameter controls not whether a program actually uses adopted authority, but rather whether a program will accept the propagation of adopted authority from a program that was called earlier in the job stack. That is, if PROGA adopts QSECOFR's authority and then calls PROGB, PROGB decides whether or not to accept QSECOFR?s adopted authority when it executes based upon the value specified in the USEADPAUT parameter. If PROGB is set to USEADPAUT(*YES), which is the default value, PROGB will accept and use the adopted authority that a preceding program has acquired. If PROGB is set to USEADPAUT(*NO), PROGB will reject PROGA's adopted authority and run only under the authority of its end user.

When speaking of adopted authority, many OS/400 professionals refer to USEADPAUT as if it controls a program's ability to adopt authority. This is simply not true. For example, if a program is set to the values USRPRF(*OWNER) and USEADPAUT(*NO), the program would adopt the authority of its current owner but refuse to accept the adopted authority of any previously called program. (This is a very handy technique for changing the adopted authority that an end user runs under, while in the middle of a job).

Just to be clear, setting parameter USRPRF(*OWNER) will cause a program to adopt the program owner's authority. Setting parameter USEADPAUT(*YES) causes a program to accept all of the adopted authority set by programs that precede this program in the job stack. And if you get confused, bypass the parameter descriptions on the CHGPGM and consult directly with the help text.

John Earl
PowerTech Group
This email address is being protected from spambots. You need JavaScript enabled to view it.

John Earl is the founder and Director of Technology and Security for  The PowerTech Group.  a Seattle-area software company that specializes in System i security. He has over 25 years experience with IBM midrange systems and security, has published numerous articles and columns for industry magazines, and served as a Subject Matter Expert (SME) for Security for COMMON. A highly regarded speaker on OS/400 and i5/OS security, Mr. Earl has presented several hundred of iSeries security sessions at industry conferences and user groups all over the world. He is a three-time winner of COMMON's Speaker Excellence award and has also served on the board of directors of COMMON U.S.

 

He can be reached at 253.872.7788 or at This email address is being protected from spambots. You need JavaScript enabled to view it..