Re: STG(*FREE) on SAV* commands...

Graap, Kenneth wrote:

Does anyone utilize the STG(*FREE) option that is available on most of the SAV commands?

The reason I ask is that having access to the SAV* commands and also having *SAVSYS Special Authority, gives a user the authority
to effectively delete any object on the system, by using the STG(*FREE) parameter.

If this is the only concern being expressed for a user having the special value *SAVSYS, then there are surely more serious concerns being overlooked. Since only the "data" portion of the object is removed rather than the object [and thus its authorities, etc.], IMO "effectively delete" is a bit

Example -

SAVOBJ OBJ(UFILE1) LIB(PRODLIB) DEV(*SAVF) OBJTYPE(*FILE) SAVF(MYLIB/MYSAVFILE) UPDHST(*NO) STG(*FREE)
DLTF FILE(MYLIB/MYSAVF)

Deleting the object would defeat the point of saving *FREE; i.e. the given script, with the delete file request, is then little different than having saved with STG(*KEEP). Also, the *SAVSYS gives no special ability to DLTF, beyond data removal achieved by the STG(*FREE) which was enabled by *SAVSYS; i.e. the DLTF would have failed expect if authorized to the user, perhaps by *ALLOBJ special authority. Thus presumably the inclusion of DLTF in the above example was not intended.?

Being able to save objects that a programmer or operator doesn't have direct authority to, may be a useful function that Special Authority *SAVSYS addresses, but the security risk associated
with STG(*FREE) makes giving this authority to anyone extremely
risky.

The bigger security problem for the Save System special authority is actually for the ability to *restore* objects. Saving is a concern too, especially for STG(*FREE) [due more to implications in difficulties that can be experienced from misuse of suspended objects than for the security aspects].

I understand that there are ways to mitigate this risk. The easiest is to severely restrict who gets *SAVSYS Special
Authority OR restrict access to the SAV* commands OR force
STG(*KEEP) via an exit or validity checking program.

Better IMO to just limit that special authority to individuals who can be trusted, just as what must be done with other special authorities. All special authorities require a level of trust beyond just private authorities.

But if there isn't really any reason to free storage in the first
place, we wouldn't have to worry about this security risk at
all...

The ability to save "storage freed" enables leaving the object and the private authorities [etc.] intact, while removing the storage required for its data. There are valid reasons to /suspend/ the objects using the feature provided on the save commands.

This is why I'm wondering what the original purpose of having the
STG(*FREE) option might have been...

Offline storage while maintaining ownership & authority for the object. Later the suspend feature implementing STG(*FREE) enabled the auto-restore feature for nearline storage capabilities. The automatic restore is most effective using "robot" magnetic media libraries; i.e. media can be chosen, loaded into a device, and restored from without operator intervention.

Is this something IBM should consider removing from the SAV
commands?

No. Those depending on the function would be impacted from an incompatible change. Many customers are using BRMS, ROBOT, and other functions for B&R built over SAV* using STG(*FREE), using the feature most probably along with the auto-load\restore feature to bring the data online "on demand".

Discussion ... Comments ????

Regards, Chuck