× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I agree... Deleting the *SAVF would defeat the point of using STG(*FREE) ... That is the point. You can do exactly that.

The point I was trying to make in my example though, is that if a user with *SAVSYS authority saved a file to a SAVE FILE using STG(*FREE) and then deleted the SAVE FILE, the object would effectively be removed from the system, because the data portion of the object is gone and it couldn't be restored because the save file containing the data was also removed. Since the user executing this SAV command creates the SAVE FILE they could delete it without having *ALLOBJ authority because they own it.

Kenneth
Kenneth E. Graap
http://www.linkedin.com/in/kennethgraap


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, December 07, 2009 10:21 AM
To: midrange-l@xxxxxxxxxxxx
Subject: 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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.