Discovering Problems with Private Authorities

By Dan Riehl

When an object is created, it is owned by either the user that created the object or by the user's primary group profile. Ownership depends on the OWNER attribute of the user profile. If the value is set to OWNER(*GRPPRF), objects created are owned by the user's primary group, if OWNER(*USRPRF) is specified, objects are owned by the user, not the group.

To view objects owned by a user profile you can use the command:

WRKOBJOWN USRPRF(DRIEHL)

In addition to ownership, a user can be assigned explicit private authority to an object using the command GRTOBJAUT(Grant Object Authority), or by adding a user from the EDTOBJAUT(Edit Object Authority) display.

Normally, we want to avoid adding private authorities to an object. We typically want all of our User objects to be secured by an authorization list containing group profile names, and not individual user names.

Once we start down the path of assigning private authorities at the user level, rather than at the group profile level, we begin to build an overly complex security scheme that will require constant maintenance as users come and go. Using Authorization Lists and Group Profiles in our authorization settings provides the least complex configuration, and requires the least amount of on-going maintenance. We do not have to make additions and changes every time a new user is added, or when a user's job function changes. In those cases, we simply assign the user to the correct group profile.

Problems in Assigning Private Authorities to Users

Any private authorities that exist, should be assigned at the Group profile level. But, alas, our systems have evolved over time, and what we typically have is a hodgepodge of mixed ownership and numerous private authority inconsistencies.

One of our aims should be to remove private authorities that exist for individual users, and reassign the authority to their group. That is, if the private authority is really needed at all.

IBM has provided the command WRKOBJPVT(Work With Objects by Private Authority). The command is used to list all the private authorities that are held by a user.
(NOTE: If the user is the owner of the object, the object will not be included in the Private Authority report. Ownership is reported using the WRKOBJOWN command as discussed above.)

Here is a command to list all the private authorities that are in place for user profile DRIEHL, and the resulting report.

WRKOBJPVT USRPRF(DRIEHL)

                     Work with Objects by Private Authority                     
                                                                                
 User profile . . . . . . . :   DRIEHL                                        
                                                                                
 Type options, press Enter.                                                     
   2=Edit authority   4=Delete   5=Display authority   7=Rename                 
   8=Display description                                                        
                                                                                
                                                                ASP             
 Opt  Object                Library       Type      Attribute   Device          
      SECURITY              QSYS          *LIB      PROD        *SYSBAS         
      DRIEHL                QSYS          *USRPRF               *SYSBAS         
      CHARTX12              QUSRSYS       *MSGQ                 *SYSBAS         
      CLASSUSER             QUSRSYS       *MSGQ                 *SYSBAS         
      DANRIEHLB             QUSRSYS       *MSGQ                 *SYSBAS         
      DRX234BP              QUSRSYS       *MSGQ                 *SYSBAS         
      GROUPOPS              QUSRSYS       *MSGQ                 *SYSBAS         
      GROUPPRG              QUSRSYS       *MSGQ                 *SYSBAS         
                                                                
                                                                More... 

Our objective in this context should be to remove as many private authorities as possible from the user id, and if needed, assign any private authorities to group profiles only.

Caveat: Each user will have, and should retain, a private authority to their own user profile and to group profiles for which they are a member.

     

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn