Fixing Your Save/Restore Authority Problems

By Dan Riehl

How often have you found yourself bewildered when restoring a production library to a test or backup system only to find that the authorities on the test system don't match the authorities on the production system?

I can't tell you the number of times I've received a call from a client trying to figure out why their authorities are not consistent between the two systems. Restoring objects from one system to another and trying to keep all the security-related attributes and authorities intact can be a challenging process. There are numerous rules that come into play, depending upon how the objects are saved and how they are restored.

IBM made a very nice enhancement to the Save(SAVxxx) and Restore(RSTxxx) commands back in IBM i version 5.4 that ease the pain of trying to get the authorities right on your restored objects. You still need to be aware of the rules and restrictions of saving and restoring objects, but this updated support will be the answer to many of your restore difficulties.

The Problem

Before delving into the enhanced support provided in 5.4, let's consider an example of how Save/Restore operations work in relation to object private authorities.

The only object authorities that are saved and restored with an object are the object Owner's authority, the *PUBLIC authority, and the Object Primary Group. These authorities are stored within the object and are therefore saved with the object; however, NONE of an object's private authorities are stored within the object. They are stored within the User Profiles of the users that have a private authority to an object.
(Note: If the object is secured by an Authorization List, the list name is stored in the object. So, the list name is saved with the object.)

So, If Joe has an authority of *CHANGE to the PAYROLL library, and Joe is not the owner of the library, Joe's 'private authority' is not saved, and thus cannot be restored with the object. It's just gone on the restore side. Poof!

Prior to the 5.4 enhanced support, these object private authorities were only saved when user profiles were saved, using the Save Security Data (SAVSECDTA) or Save System (SAVSYS) commands.

Restoring the object private authorities on to another system required a two-step process, not including the actual Object/Library restore process. First you had to restore the user profiles. The command Restore User Profile (RSTUSRPRF) is designed for that purpose. Once your selected user profiles had been restored, the command Restore Authority (RSTAUT) could be used to restore the private authorities from selected user profiles back to the restored objects.

The Updated IBM i 5.4 Support to Save and Restore Private Authorities

In 5.4, IBM introduced the Private Authority (PVTAUT) parameter to the Save and Restore commands. The setting of the PVTAUT parameter will determine whether private authorities are saved and/or restored WITH the objects.

This updated capability can save you a significant amount of time, effort, and aggravation in moving objects from one system to another while keeping the private authorities intact. You obviously are still subject to the rules and restrictions for Save and Restore operations, but using this 5.4 PVTAUT support, you no longer need to Save and Restore user profiles, and you do not need to do the RSTAUT operation in order to get your private authorities in synch for selected objects.

So, when saving and restoring a file named PAYFILE, the private authorities can be saved and restored with the PAYFILE file object:

SAVOBJ OBJ(PAYFILE) LIB(PAYLIB) . . . PVTAUT(*YES)

RSTOBJ OBJ(PAYFILE) SAVLIB(PAYLIB) . . . PVTAUT(*YES)

More About the PVTAUT Parameter of Save and Restore Commands

The default value of PVTAUT on all Save and Restore commands is *NO, so if you want private authorities to be saved and restored with the objects, you will need to specify PVTAUT(*YES).

In order to restore the private authorities using a RSTxxx command with PVTAUT(*YES), you first need to have save media that was created using SAVxxx . . . PVTAUT(*YES). (i.e. You need to save the private authorities if they are to be restored.)

This PVTAUT support is great when moving selected objects, or entire sets of libraries from one system to another, but it is not recommended when performing your daily/weekly routine save operations like SAVLIB *NONSYS or SAVLIB *ALLUSR. It is mainly for a one time load when you need to duplicate a system or application across systems and keep the authorities in synch.

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