Previous to the i5/OS operating system that we all know and love, there was a predecessor named Control Program Facility (CPF). Back in these olden days of the CPF operating system on the IBM Sys/38, the people doing your nightly backups needed to have *ALLOBJ special authority to be able to save all the objects on the system. If they tried to back up the entire system without having *ALLOBJ authority, they'd received error messages that said "Not authorized to Object XYZ" for each object they were not authorized to save. So, the system was not fully saved. This *ALLOBJ issue was an exposure that none of us liked much, in that we did not want to provide *ALLOBJ authority to all the operations staff.

IBM fixed this problem in a later release of CPF by creating the new special authority of *SAVSYS. This new special authority allowed the operators to back up all the objects on the system, even though they had no authority to the objects. ( I am showing my age in this discussion. But I bet many of our readers worked with these early releases of CPF.)

So today, we have *SAVSYS special authority that allows the user to back up anything using SAVxxx commands like SAVLIB, SAVOBJ, SAV, etc. The saved data can be written to a tape device or image, or to a save file on disk.

The Security Implications of *SAVSYS

Many issues arise when the *SAVSYS special authority is considered. For example, users with *SAVSYS special authority can delete your most sensitive files, even though they have no authority to the files.

The Storage(STG) parameter of the SAVxxx commands allows you to specify the value of STG(*FREE), which in the case of saving a file, removes the file's data from the system after the save operation is completed. The object and member definition remains, but the data is removed.

SAVOBJ OBJ(MYFILE) LIB(MYLIB) DEV(TAP01) STG(*FREE)

So, as long as you want to allow users to delete any sensitive data, assign them *SAVSYS special authority.

Another security area that deserves our attention is the fact that a user with *SAVSYS special authority can back up any file or an entire library to a save file. The save file can then be downloaded using FTP or iSeries Access file transfer to the user's PC. The transferred save file can then be sent off-site via e-mail to anyone in the world. Even though the user has no authority to the file or library, it can be saved and sent to anyone with a System i, and then all the data is available to anyone on the other end of the transmission. Talk about a data leak!

Imagine your sales database being sent to your biggest competitor. Imagine your medical records system being sent to the far east. How long would it take to appear on the internet?

Giving *SAVSYS special authority to a user is a potentially dangerous act.

My suggestion is that you make sure that no user is assigned *SAVSYS special authority. The exception is IBM-supplied profiles and a service user profile with no password (CRTUSRPRF …PASSWORD *NONE) that is used by your backup system. When no password is specified, no one can sign on as that powerful user.

As in *ALLOBJ special authority, *SAVSYS is just too dangerous to pass out indiscriminately.

Who Has *SAVSYS Special Authority?

If you do not have a better reporting tool, you can use the IBM-supplied command PRTUSRPRF(Print User Profile).

PRTUSRPRF TYPE(*ALL) SELECT(*SPCAUT) SPCAUT(*ALL)

This command generates a list of user profiles that includes all the special authorities assigned to the user and the value of the Limit Capability flag in her user profile. Any special authorities held by the user or by any group profile of which the user is a member are listed.

There is one issue with this command that you need to be aware of.

Let's say you only want to list users with *SAVSYS (Save System) special authority. You would probably enter the command as shown here.

PRTUSRPRF TYPE(*ALL) SELECT(*SPCAUT) SPCAUT(*SAVSYS)

The problem is that unless the *SAVSYS special authority has been assigned to a user's individual user profile, her user profile will not appear on this list, making it appear that the user does not have *SAVSYS. If the user is a member of a group profile that has *SAVSYS authority, the report is can be quite misleading.

Since a group profile's special authorities cascade down to the individual user profile level, if the group has *SAVSYS, all members of that group have *SAVSYS.

To avoid this reporting issue, specify the command as follows. Then all special authorities held by the user, and by the user's groups, will be listed.

PRTUSRPRF TYPE(*ALL) SELECT(*SPCAUT) SPCAUT(*ALL)