August 15, 2012 - Vol 2, Issue 15
Fixing your Restore Inconsistencies in Private Authorities
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 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 in IBM i version 5.4 that can 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 new support will be the answer to many of your restore difficulties.
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, all of an object's private authorities are not stored within the object. They are stored within the user profiles of the users who have a private authority to an 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.
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 requires a two-step process, not including the actual Object/Library restore process. First you must restore the user profiles. The command Restore User Profile (RSTUSRPRF) is designed for that purpose. Once your selected user profiles have been restored, the command Restore Authority (RSTAUT) can be used to restore the private authorities from selected user profiles back to the Objects/Libraries.
The 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 new 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 libraries and objects 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.
About the AuthorDan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group, LLC.
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.