The Dangers of Abusing IBM-Supplied Profiles

When OS/400 is installed, numerous user profiles are created on your system. More profiles are added with each release to support new OS features or other IBM products. A core set of profiles-QSECOFR, QPGMR, QSYSOPR, QUSER, QSRV and QSRVBAS-has been around forever. But just because they've been around-and will stay around-is no excuse for abusing them.

While QSECOFR is one of the most powerful profiles, it has its limits and is being overworked. Many vendors and application providers require customers to sign-on with this profile to install their applications. This practice is unnecessary. Installation routines shouldn't require anything that *ALLOBJ profiles and possibly a few of the other special authorities couldn't do just as well as QSECOFR. Some companies try to protect QSECOFR from this abuse, but vendors cause them to compromise their standards and require its use.

Using QSECOFR for daily tasks is another form of abuse. Few operations require QSECOFR to be the process user profile, so it shouldn't be used for a general-purpose sign-on. Create another user profile that has most or possibly all security administrator special authorities. Having a specific profile assigned to an individual assures that accountability is preserved-that is, the user who performed a specific task can easily be identified.

Rather than creating an application-specific profile to own an application, developers often choose QSECOFR as the owner. This practice bloats the QSECOFR profile and makes it difficult for system administrators to identify potentially dangerous programs because it's harder to spot programs that are inappropriately adopting QSECOFRs profile. In many cases, too many programs are owned by QSECOFR to investigate and track.

QPGMR is also often assigned as an application owner, but I more frequently see it used as a group profile. Making any of the IBM-supplied profiles a group profile can be dangerous, because OS/400 ships these profiles authorized to many and owning a few OS/400 objects. I encourage you to run the Display User Profile (DSPUSRPRF) command, specifying the *OBJOWN parameter. Then run it again specifying the *OBJAUT option. Examine the lists produced and ensure you want those users to also be authorized to or own the objects listed.

Realize, too, that any special authority that the group has, the members will also have. Several releases ago, the default special authorities for each user class were reworked. It was decided that the programmer user class shouldn't be defaulting to give users *SAVSYS and *JOBCTL authorities. Why would programmers need the capability to save or restore any object on the system regardless of their authority to that object? However, for compatibility reasons, the QPGMR profile didn't have these two special authorities removed. Therefore, when you assign a programmer QPGMR as its group profile, you've given that programmer *SAVSYS and *JOBCTL special authorities. I've seen QSYSOPR suffer the same type of abuse.

















Carol Woodbury is a technical editor for IBM Systems Magazine, Power Systems — IBM i edition and co-founder of SkyView Partners, Inc. Carol can be reached at

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.


A Guide to Passing an Audit


A Look at COBIT Security

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters