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