Controlling Adopted Authority

By Rich Loeber

IBM i programs have a setting when compiled that controls the user profile that will be used for security reasons when that program runs. You may think that your security configuration is all set and that you've made a final determination as to which users are allowed to have access to what objects on your system. But, if a program on your system is compiled with the USRPRF attribute set to *OWNER, then all your preparation work may be out the window.

The USRPRF parameters for most program compilation commands is set to a default value of *USER on most systems. This is the way it comes from the factory although it is easy for the default setting to be changed. When programs are compiled with the *USER setting, then you can count on your object security setup to provide the proper control over access to objects on your system. When this gets changed, however, then the access controls are based on the owner of the compiled *PGM object and not on the user profile of the person that is running the *PGM object. (Note: This also applies to *SQLPKG and *SRVPGM objects, but for the purposes of this article, I'm just referring to all of these generically as "programs".)

This situation is called adopted authority. There are lots of good reasons why you would want to do this. For example, you may have a CL program that creates backups of your system that is run by your night operator. You may not want your night operator's user profile to have all object authority, so you compile the CL program under a user profile that does have all object authority with the USRPRF parameter set to *OWNER. Then, when the night operator runs the backup, it goes off without a hitch. While the backup is running, it has access to the objects needed to complete the backup but the night operator profile is still restricted. A lot of third party software developers use this technique to make sure that their programs can run without authority problems.

To make sure that your security is not being compromised by adopted authority issues, you should do a periodic review of programs that use this technique.

The first step is to identify the user profiles in your system that have all object authority. This step alone might produce some interesting results that will surprise you. One quick way you can do this is by running the following command:

DSPUSRPRF USRPRF(*ALL) OUTPUT(*OUTFILE) OUTFILE(QTEMP/USRPRF)

This will create a temporary physical file named USRPRF in your QTEMP library. Once created, you can scan this file for the value *ALLOBJ in the first 7 positions of the field designated as UPSPAU. Any query tool that you like should give you a quick report on what you're looking for. Check each profile listed to make sure there are no surprises.

Then, to see if there are any programs that adopt any of the profiles on your list, use the DSPPGMADP command for each profile. This command supports on-screen display, print and *OUTFILE output. Use the form that best suits your needs. At a minimum, you should check for programs that adopt the QSECOFR user profile. The command to review this looks like:

DSPPGMADP USRPRF(QSECOFR)

Once you have identified programs that run under a user profile that has all object authority, you should then determine if the requirement for adopted authority is absolutely necessary. In some shops where I've worked, I have identified programs adopting the QSECOFR profile because it corrected a problem during testing and was just left that way in production. One obvious problem would be if the program in question has an option to present the user with an IBM i command line. In this situation, the user then has full access to your system that goes right around your careful security setup plans.

For third party software, contact your software provider and ask about the adoption situation. A good software provider should have a ready answer for this question.

When you've identified a program that needs to be changed, you don't need to recompile to make the change. A simple Change Program command will work in most instances. Use the following command to change from adopted authority to user authority:

CHGPGM PGM(MYLIB/MYPGM) USRPRF(*USER)

If you have any questions about anything in this tip, just ask me and I'll give you my best shot. My email address is rich at kisco.com. All email will be answered.