ABR Auto-Recall – Security


Security considerations

There are special security considerations for auto-recall of archived data sets

As described in Security in FDRABR-Processing-Options-and-Requirements, allocating and restoring a data set requires ALTER authority to that data set. Even adding a restore request to a remote queue with FDRABRUT requires ALTER authority. However, recalling a data set is not really creating it; it is simply moving it back to DASD from a less expensive storage medium such as tape. A user with only READ authority to a data set should be able to recall a data set and open it for input.

This dilemma can be avoided by activating the LXCHKSEC and LXBYPSEC options (see LXCHKSEC and LXBYPSEC in ABR Auto-Recall – Customization Options).

LXCHKSEC

When LXCHKSEC is “YES”, the ABR Catalog Locate exit will check the caller's authority to the data set (in security class DATASET) before it even invokes FDRABR to do the recall or FDRABRUT to add the request to the remote queue. If the user does not have the proper authority, the recall will not be attempted.

It checks for READ authority to the data set, so that a user with only read access can recall the data set and read it. This does not present a security exposure even if the user is trying to write to the data set, because after the data set is recalled, OPEN still performs the normal security checks. At worst, some DASD space is wasted by recalling a data set that the user is not able to access, until the data set becomes eligible to be archived again.

However, when the output volume has been changed (by the LXCONUSE option, the LXEXIT recall exit, or the FDR Data Set Security exit), the security check is for ALTER authority. This does not apply if a TSO user modifies the output volume serial number via a response to the FDRW77 message.

This security check is always done in the address space of the requester, even if the recall is performed as an external recall.

The LXCHKSEC option will not check for authority to the output volume (in the DASDVOL security class) because the output volume serial may be changed by ABR or SMS.

The Data Set Not Found exit does no security checking of its own.

LXBYPSEC

When LXBYPSEC is “YES”, the ABR Catalog Locate and Data Set Not Found exits cause all security checking to be bypassed when they invokes FDRABRUT to add the restore request to the remote queue (ABR Catalog Locate exit only), or FDRABR to perform the restore. All security checks from FDRABR, FDRABRUT, and system services (such as allocation) are suppressed. This allows any user to recall any archived data set, but there is no security exposure since normal security checking is back in effect when the data set is opened.

This also allows ABR to read Archive Backup files to which the user may not be authorized at all.

LXBYPSEC bypasses security checking for all foreground and external recalls. However, for remote queue restores, it bypasses the security checks done by FDRABRUT before adding the request to the queue, but does not affect the actual restore. The ABR RESTORE TYPE=ARC job that processes the request on the remote queue must have authority to allocate and restore all data sets on all volumes. You may want to run that restore job under a user ID that is exempt from security checking (for example, IBM RACF OPERATIONS attribute).

The security bypass invoked by LXBYPSEC is effective for IBM RACF, CA ACF2, and CA TOP SECRET.

Tip

We recommend that you enable both LXCHKSEC and LXBYPSEC. This allows users with only READ authority to recall a data set

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*