June 20, 2012 - Vol 2, Issue 11
Cilasoft EAM - Control Powerful Users

Is Your JD EDWARDS Database Secure? See how SKYVIEW PARTNERS can help!

Mysteries of the QUSEADPAUT System Value

By Dan Riehl

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 subprograms. Whenever a program adopted authority, downstream programs had no way to turn off that adopted authority.

A short History of QUSEADPAUT

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:


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).



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:

   CallPrc Prc( '_MODINVAU' )  Parm(x'01') /* Suppress Adopted Aut */ 

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, LLC.

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