Give AS400 users the ability to change user authority temporarily

More questions about adopting authority on IBM i Systems and a technique to change user authority temporarily. So lets #discuss 😉

Adopt higher IBM i Authority to change System Configuration

Question: I am needing to write a program, command, or whatever, that will enable my users to adopt a higher authority when they want to delete or vary on/off a device. All the users will be at *USER. What would be the best way for me to do this?

Answer 1. Give the folks that need to do that *IOSYSCFG special authority.

(Note, according to another post, this doesn’t do it. IOSYSCFG doesn’t provide authority to the objects themselves. Create commands to handle these which adopt authority and call the OS/400 native commands. Restrict access to these commands.)

Answer 2. Create a program do do the desired function and compile it with with USRPRF(*OWNER)… after the *PGM object is compiled, change it’s owner to that of QSECOFR.

Then, when this program is run, the authority of QSECOFR will be used to run the program.

Ensure that the program can ONLY do what you specify… Programs like this should be very limited. Don’t do anything other than the function that requires the extra authority, and never allow access to a command line while the program is active.

I would recommend that you qualify any commands (VRYCFG, etc) with the appropriate library (QSYS/VRYCFG).

Answer 3 (combines answers 1 & 2). To change or delete a device the user must have *IOSYSCFG special authority. If you want to adopt this authority (a good choice), The look at the CRTxxxPGM command and/or the CHGPGM commands. There is a parameter called USRPRF that defaults to *USER (run under the authority of the user). You can change this parameter to *OWNER (run under the authority of the program’s owner). You’ll then want to change the ownership of your program (CHGOBJOWN) to a user profile that has *IOSYSCFG special authority.

Question (multipart): I’ve got two ‘adopted authority’ questions:

PRG-AUTH adopts authority, PRG-NOAUTH doesn’t.

1. If PRG-AUTH calls PRG-NOAUTH, does PRG-NOAUTH run with the users authority or with the authority adopted by PRG-AUTH?

2. If PRG-AUTH transfers control (TRFCTL) to PRG-NOAUTH, does PRG-NOAUTH run with the users authority or with the authority adopted by PRG-AUTH?

Are there any gotchas with either scenario?

Answer 1 part 1 In this scenario PRG-AUTH remains in the stack above PRG-NOAUTH so PRG-NOAUTH uses the adopted authority of PRG-AUTH.

Answer 1 part 2 In this case PRG-AUTH is no longer in the stack so PRG-NOAUTH does not adopted authority from it. Answer 1 part 3 In order to adopt authority the USEADPAUT parameter of PRG-NOAUTH must be set to *YES. If it is set to *NO the program will be unable to adopt authority from a program higher in the stack.