Warning: Declaration of TCB_Menu_Walker::walk($elements, $max_depth) should be compatible with Walker::walk($elements, $max_depth, ...$args) in /home/nicklit/www/www/wp-content/plugins/thrive-visual-editor/inc/classes/class-tcb-menu-walker.php on line 620

Warning: session_start(): Cannot start session when headers already sent in /home/nicklit/www/www/wp-content/plugins/userpro/includes/class-userpro.php on line 222
IBM i Users adopting higher authority rights - Nick Litten is IBM-i, AS400 iSeries RPG Programmer and Nerd

IBM i Users adopting higher authority rights

IBM i

Feb 05

More questions abvout adopting authority on IBM i SYstems. So lets #discuss 😉

Adopt higher iSeries 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.

Question: I have a batch job which is run by the user but needs to use a file with security denied to the user. Somewhere I heard or read about adopt authority, which would allow the job to use the file if the adopted authority was granted

Answer 1. Happens all the time in packaged software. Change the owner of the program to a profile that would have authority, then use the change program command with adopt authority *yes and usrprf *owner.

CHGOBJOWN OBJ(PROGRAM) OBJTYPE(*PGM) NEWOWN(QSECOFR) CUROWNAUT(*SAME)
CHGPGM PGM(PROGRAM) USRPRF(*OWNER) USEADPAUT(*YES)

Question: While doing some testing I found several system facilities that ignore adopted authority, several areas have work-arounds, but triggers in particular do not. At this point I suspect that adopted authority is only viable in a discrete application. Does anyone know where I can find a list of system supplied programs and functions that ignore adopted authority? Are there any other ways to end adoption other than the specifying USEADPAUT(*NO) on the program or MODINVAU MI instruction? If there are no other ways to end adoption, is possible to find all programs that use MODINVAU? (4/2000)

Answer: To find out programs that use MODINVAU, try this command DSPPGMREF

Follow

About the Author

IBM i Software Developer, Digital Dad, AS400 Anarchist, RPG Modernizer, Alpha Nerd and Passionate Eater of Cheese and Biscuits. Nick Litten Dot Com is a mixture of blog posts that can be sometimes serious, frequently playful and probably down-right pointless all in the space of a day. Enjoy your stay, feel free to comment and in the words of the most interesting man in the world: Stay thirsty my friend.