On your iSeries, every object is owned by a user profile, even if it is just a system default-owner profile. As objects are created, the person who creates the object establishes the ownership. When new objects are added to your system that were created on a different system, such as third-party software or objects restored to your system from another iSeries, the ownership that was in effect on the other system is carried over onto your system.
Program objects have a unique aspect of ownership that many programmers and users of OS/400 may not be aware of. There is a setting in each *PGM object on your system that controls authority checking whenever that *PGM object is executed on your system. This is controlled by the USRPRF parameter when the program is compiled. For existing programs, it can be changed by the CHGPGM command.
The default setting for the various compilation commands in OS/400, as shipped from the factory, sets the USRPRF parameter to the value "*USER". This means that when that program runs, the security settings are checked according to the user profile in effect for the user who actually runs the program. This is the intuitive setting that you would normally want to have in effect. When users run a program, you only want them to have access to objects on your system with which they are authorized to work. If they run a program that they are not supposed to be using, one that accesses objects for which they have no authority, for example, then you want OS/400 security to kick in an prevent the object access. As long as your programs are set to *USER for the USRPRF parameter, then this is exactly what will happen.
The alternate setting for the USRPRF parameter in programs is *OWNER. Specify owner and the program is said to "adopt" the security settings for the user profile that owns the *PGM object (regardless of who is running the program). So, using this method, someone with fairly limited security authorization can run a program and access objects that they normally cannot. Why would you want to do this? Suppose, as an example, that a payroll clerk should have access to files for maintenance under program control, but you don't want the clerk to have access to the payroll files for any other purposes. Have the maintenance program adopt the authority of the program owner, and you can accomplish this with ease.
So, what's the problem then with adopted authority?
The problem is that it can be misused and, under certain circumstances, open your system to abuse. Because of this, you need to know which programs on your system use adopted authority and then check those programs to make sure that they are well behaved and don't break any of the generally accepted rules for programs of this type.
As an example, a program that uses adopted authority, and is owned by a user profile with *ALLOBJ authority, could lead to a security breach. If that program contains an option to display an open command line, then the user could gain access to your entire system.
When reviewing this situation, it is important also to remember that not only can security authority be adopted, it can also be inherited. This happens when a program with adopted authority run and then calls another program deeper in the program stack. That called program will inherit the adopted authority of the program that called it from higher up in the program call stack. This inheritance feature is in effect only for a single call level. If your called program then, in turn, calls a third program, then the inherit feature is no longer in effect for the third program.
OS/400 contains a reporting feature that will allow you to review programs that adopt authority so you can see where your possible exposures are. The Print Adopting Objects (PRTADPOBJ) command will let you review this on-line or via a printed report. It is run by user profile and, at a minimum, you should take a look at all of your user profiles that have *ALLOBJ authority.
This just scratches the surface of the issues associated with programs that adopt their owner's authority. For additional research, take a look at the OS/400 manual "Tips and Tools for Securing Your AS/400" - Document Number SC41-5300-04. It will show you ways to limit the use of adopted authority and provide additional insights into the issues presented.
Rich Loeber is president of Kisco Information Systems Inc., in Saranac Lake, NY. The company is a provider of various security products for the AS/400 market.
