Adopted Authority and the Mystery of QUSEADPAUT System Value

By Dan Riehl

The topic of Adopted Authority on IBM i has not been very well understood. We know that it is a method to allow a user to perform functions that they are not normally authorized to perform. But, under Adopted Authority, they can do more powerful things than what their normal permissions allow. For most programming techies, we know how to make a program Adopt the Authority of the Owner of a program, but we are unsure how that fits in with the function of the program attribute named USEADPAUT, and the mysterious System Value QUSEADPAUT.

Many think that the USEADPAUT attribute of a program determines if the program Adopts Authority, which it surely does not. It is the USRPRF property of a program that determines if the program Adopts the Owners Authority. If USRPRF(*OWNER) is specified, the program will Adopt the Authority of the Program's Owner as shown here.

CRTCLPGM PGM(MYPGM) USRPRF(*OWNER)

The program property USEADPAUT cannot be specified at compile time, but can be specified using the CHGPGM command. But, still, What does USEADPAUT actually do, and why is it set the way it is to *YES or *NO?

CHGPGM PGM(MYPGM) USEADPAUT(*YES)

A short History of USEADPAUT and The QUSEADPAUT System Value

The QUSEADPAUT system value was introduced several years ago to address the concern that there was no way to keep adopted authority from flowing down the call stack to all or a program's subprograms. Whenever a program adopted authority, called subprograms had no way to turn off that adopted authority.

I recall when we, the AS/400 user community, back then, asked IBM for a way to create an adopting program that didn't propagate the adopted authority down the stack. We wanted an attribute we could set in the adopting program that said, "This program will adopt but will not pass the adopted authority to any other program." We wanted to contain the adoption within the adopting program itself and not pass it on.

With that functionality, we could control the use of adopted authority very granularly. We could adopt authority in a program that needed additional authority and specify that the program not pass that adopted authority to any called programs. That way we could easily control which programs adopted authority and never worry about the adopted authority being propagated outside of the program. That's what we asked for.

When IBM announced its version of the solution as a PTF to version 3.1 of the OS, we were all a bit dismayed. IBM didn't let us stop the propagation within the adopting program; instead IBM let us set a flag in a called program as to whether the called program was going to use the adopted authority passed to it. It was exactly backwards from what we had asked for. I'm sure many of you remember that discussion.

We wanted control from within the adopting and CALLing program. IBM supplied USEADPAUT to provide control inside the CALLed programs. I wish IBM had done it the other way.

But, IBM ultimately got it right when they released the Built-In MI function MODINVAU, which can be used to stop the propagation of authority outside the adopting program or a program running under adopted authority. See the sidebar "Stop Adoption in the Calling Program using MODINVAU," below.

QUSEADPAUT Allowable Values

The IBM-shipped value for the QUSEADPAUT system value is *NONE. This means there's no restriction on who can create a program that uses the adopted authority passed to it.

When the system value is *NONE, each program is created with the attribute of USEADPAUT(*YES). If you want to change a program to not use the propagated adopted authority, you can change the program as follows:

CHGPGM MYPGM USEADPAUT(*NO)

The other valid value for the QUSEADPAUT system value is the name of an authorization list. Most folks who specify an authorization list specify the authorization list name as QUSEADPAUT. This is done to make the intent of the authorization list intuitive, but the authorization list can have any name.

The authorization list controls who can create and change programs that specify USEADPAUT(*YES). RPG, CL, and Cobol programs and service programs have no compiler options that let you specify the USEADPAUT value. That program attribute is handled automatically based on your authority to the authorization list.

If a user has at least *USE rights to the authorization list, all programs he or she creates will be created with USEADPAUT(*YES). If a user doesn't have at least *USE authority to the authorization list, every program he or she creates will be created with USEADPAUT(*NO), and the user won't be able to use the CHGPGM(Change Program) command to change the program to USEADPAUT(*YES).

In an ironic twist, when you create a program or attempt to change a program to USEADPAUT(*YES), your authority to the authorization list can't come from adopted authority.

Let me reiterate here that if the system value doesn't specify an authorization list name but instead is set to *NONE, all programs will be created with USEADPAUT(*YES).

Sidebar:

Stop Adoption in the Calling Program by Using MODINVAU

IBM has provided the MI built-in function MODINVAU to modify the invocation authority attributes of a program. The function has one argument that can contain one of two values:

• Hex '00' = Don't suppress Adopted user profile authority
• Hex '01' = Suppress Adopted user profile authority

If x'00' is specified, normal propagation of adopted authority to called programs and subprograms occurs. If x'01' is specified, adopted authority is not propagated to called programs and subprograms. Here's an example of using the function in an ILE CL program:

   Pgm 
   
   CallPrc Prc( '_MODINVAU' )  Parm(x'01') /* Suppress Adopted Aut */ 
   
   GO MAIN 
   
   EndPgm

This simple program uses the MODINVAU function to flip the invocation authority switch so that any adopted authority is not propagated to subsequent programs. In this case, the program takes us to the menu name MAIN, and adopted authority is not in effect. When we exit from the MAIN menu by pressing F3=Exit, we return to this calling program, where the adopted authority in that program is still in effect.

I suggest using this function heavily in your application design to get granular control of adopted authority. If a program needs adopted authority, create the program to adopt. But then also use the MODINVAU function to block the adopted authority from traveling down the stack to other programs. It's a much more elegant design than trying to take control of all programs by using the USEADPAUT program attribute.

If your adopting programs don't pass adopted authority, many security problems with adopted authority are alleviated. You can read about MODINVAU in the IBM Information Center at http://publib.boulder.ibm.com/iseries/v5r1/ic2924/tstudio/tech_ref/mi/MODINVAU.htm

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn