Feature Article

Adopted Authority and

     the Mystery of The QUSEADPAUT System Value

By Dan Riehl - SecureMyi.com

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 QUSEADPAUT

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.

Read More . .