From: Doug Payton To: All

What are the dangers of changing the default on all CRTxxxPGM commands to USRPRF(*OWNER)? We are trying to get away from granting authority to specific objects. Thanks.

From: Ernie Malaga To: Doug Payton

Compiling all programs so they adopt the authority of the owner produces a security risk. It's not as dangerous as publishing your QSECOFR's password in the morning newspaper, but I wouldn't recommend it.

For instance, you may have a CL program that runs interactively and executes one of the WRKxxx commands, which presents a command line. Or you may have an interactive program that uses QUSCMDLN, the API that presents a command line in a window. If either program is compiled adopting authority, the user will be able to execute, from the command line presented, any command that the owner is authorized to execute.

By compiling all programs adopting the authority of the owner, you're circumventing security level 30 almost entirely. You might as well go back to level 20 and be done with it. Under security level 20, all new users are created with *ALLOBJ special authority, so there are no security barriers.

Don't kill flies with a bazooka.

From: Doug Payton To: Ernie Malaga

So you recommend granting authority to specific objects? I do see your point. We just went live and had numerous authority problems, so I changed the programs to *OWNER (only the jobs that had no interaction with the user).

From: Ernie Malaga To: Doug Payton

Yes, I'd recommend you grant authority to specific objects and users. You can simplify the task with group profiles and authorization lists. Even if a program has no interaction with the user, think about this: Any user could submit the program to batch, even if he/she is not otherwise authorized, and get the job to run, because the program is adopting authority.

If you used authorities for objects/users, the program would fail if the user who submitted the program didn't have the proper authority. It makes for a more secure system.