Protecting Resources › PDS Member Protection

PDS Member Protection

PDS member level protection allows PDS data sets to be secured or audited at the member level.

With PDS member level protection, PDS member‑names become a general resource securable at the READ or UPDATE level. A control option identifies which data sets require PDS member level protection. Once enabled, access to every PDS member is secured regardless of the access method or program type.

PDS member level protection does not replace normal data set security. A user with read access to a PDS can be restricted to reading only selected members. A user with update access to a PDS can be restricted to specific members that can be read and or specific members that can be updated.

PDS Member Level Protection

The PDSPROT control option statement activates PDS member level protection and identifies the PDS data sets to be protected at the member level. A PDSPROT control option statement identifies a PDS to be protected, optionally its volume serial, and names the resource class to be used for member level access checks.

The same resource class may be named on multiple PDSPROT control option statements allowing several PDS data sets to share a common set of member level rights. Five resource classes named PDSMEM1 through PDSMEM5 are predefined in the TSS Resource Definition Table (*RDT*) for this use. For example:

PDSPROT(ADD,DSN(SYS1.PARMLIB,VOL(yyyyyy),CLASS(PDSMEM1))
PDSPROT(ADD,DSN(SYS1.PARMLIB),CLASS(PDSMEM2))
PDSPROT(ON)

TSS ADDTO and PERMIT commands setup and administer security over PDS members. TSS PERMIT commands are used to grant access to PDS members. A PERMIT may grant READ or UPDATE authority and a PRIVPGM restriction may be included.

If PDSPROT is being used with CA PDSMAN, set FASTSTOW=N in the CA-PDSMAN startup parms. This setting allows other products to share STOW processing.

Example: PDS member level protection

This example establishes member level security to allow user1 to read member IEASYS00 of SYS1.PARMLIB and user2 to update this member using ISPF Edit:

TSS ADDTO(anydept) PDSMEM1(IEA)

TSS PERMIT(user1) PDSMEM1(IEASYS00)
                  ACCESS(READ)

TSS PERMIT(user2) PDSMEM1(IEASYS00)
                  ACCESS(UPDATE)
                  PRIVPGM(ISREDIT)

Member Level Protection Exemption

To exempt a particular user or program from member level checks set up a single PERMIT allowing ALL access to a special PDS member named <BYPASS>. Then, whenever a PDS secured at the member level is opened, CA Top Secret issues a resource check to learn if the current user or program has ALL access to the special <BYPASS> member name. If it does the user or program is exempt from all further member level protection. To take effect, the program accessing the <BYPASS> PDS must be loaded from an authorized library.

Example: exempt member level protection

This example exempts user1 from member level protection when executing the GIMSMP program only:

TSS PERMIT(user1) PDSMEM1(<BYPASS>)
                  ACCESS(ALL) 
                  PRIVPGM(GIMSMP)

Implicit Access to the PDS Directory

A PDS directory exists at the physical beginning of every PDS data set. The directory tracks the name and address of every PDS member. Even though member level‑protection is active, CA Top Secret implicitly allows read access to the entire directory. For instance, when listing a member directory with ISPF or IEHLIST, a user sees the names of members the user is not allowed to access. Violations occur when explicit READ or WRITE access occurs on the protected member.

The following commands protect members at different access levels:

TSS ADD(dept) PDSMEM1(MEM)               
TSS PER(testuser) PDSMEM1(MEM1) ACC(READ) 
TSS PER(testuser) PDSMEM1(MEM2) ACC(UPDATE)

When the PDS directory is displayed, the protected members are displayed. For example:

Name     Prompt    Size
. MEM1                         
. MEM2                         
. MEM3                         
. MEM4

If ACID(testuser) attempts to READ members MEM3 or MEM4 (in any data set associated through PDSPROT with the class PDSMEM1), he is rejected. ACID(testuser) is able to select MEM1 and MEM2, but is prevented from saving changes in MEM1. In this example resource class PDSMEM1 is associated with data set SYS1.PARMLIB.

Explicit Access of a PDS Directory

Implicit access to the PDS directory occurs whenever a PDS member is updated, saved, deleted, or renamed with high‑level access methods. The directory is not explicitly updated by the calling program. It is implicitly updated by the operating system. Such access does not require explicit permission to the directory.

Programs which perform more sophisticated low‑level block updates to the PDS may never explicitly address the directory, or perform directory access for an individual protected member (for example, using EXCP or BSAM access methods).

Examples: PDS directory access

This example directs CA Top Secret to prevent low‑level writing to the directory blocks by protecting the “pseudo‑member” <DIR>:

TSS ADD(dept) PDSMEM1(<DIR>)

This prevents users from performing a compress, for instance using the IEBCOPY utility. Such protection does not prevent implicit update of the directory during the rewrite of an individual member. This protection is only invoked during low‑level block functions. To allow directory access you can permit access to <DIR>.

This example permits testuser to compress SYS1.PARMLIB:

TSS PERMIT(testuser) PDSMEM(<DIR>)
                      ACCESS(ALL)

Accidental PDS Corruption Prevention

A user may forget to specify a member name when allocating an existing PDS for output. This destroys the PDS directory. For example:

//OUTPUT DD DSN=IMPORTANT.PDS(NEWMEM1),DISP=SHR  <‑ Desired this...
//OUTPUT DD DSN=IMPORTANT.PDS,DISP=SHR           <‑ but coded this

This exposure is resolved using PDS member level protection. This accident generates a PDS member level security check for the special <DIR> resource. Only a small number of programs have authority to perform an explicit PDS directory update like this. Since no PERMIT exists the accidental access is stopped.

FETCH/EXECUTE Access of PDS Members

PDS member level protection does not secure the execute or fetch access of PDS members from PDS load libraries. Access is secured by the existing PROGRAM resource class. PDS member level protection may be useful for PDS load libraries as it restricts the ability of any user to copy, scratch, update, linkedit, or rename load library members.

PDS ALIAS Names

PDS member level protection addresses ALIAS name concerns. To:

• Create an ALIAS the user must have update access the ALIAS name being created and the root member name to which the ALIAS is attached
• Delete an ALIAS the user must have update access for the ALIAS name
• Read a PDS member the user must have read access for the root member name

These features ensure that secured PDS member access is not compromised by a user creating an accessible ALIAS name and ensures that unauthorized ALIAS names are not created.

Secure Related Diagnostic Programs

Three PDS member level protection utility programs are provided whose execution should be secured by CAPDSSEC resources within the IBMFAC resource class.

Example: secure diagnostic programs

This example defines security ownership for the PDS member level protection utility programs resources and permits their use by “USER1” alone:

TSS ADDTO(anydept) IBMFAC(CAPDSSEC)

TSS PERMIT(USER1) IBMFAC(CAPDSSEC.TERM)

TSS PERMIT(USER1) IBMFAC(CAPDSSEC.STATUS)

TSS PERMIT(USER1) IBMFAC(CAPDSSEC.TRACE)

PDS and PDSE Member Level Protection Usage Notes

When using PDS member level protection:

• SYS1.IMAGELIB is unique among data sets in that it is processed via the IMGLIB macro (SVC 105), and is not OPENed. Because it is not OPENed, the information in the DCB and DEB is unreliable, and there is no TIOT or JFCB from which to extract information. Therefore, SYS1.IMAGELIB cannot be protected at the member level.
• PDS member level protection requires MVS/ESA 4.3.0 or above.
• All forms of PDS access are secured including QSAM, BSAM, BPAM and EXCP.
• Member level protection is enabled only for the PDS data sets that are listed via a PDSPROT control option statement. No additional overhead is incurred for other data set types, for non‑listed PDS data sets, or for users with <BYPASS> authority.
• PDS member level PERMITs may grant READ or UPDATE access.
• Permission to the special <DIR> pseudo‑member should be granted at the UPDATE or ALL access level. Permission may be denied with the NONE access level.
• Permission granted at any other access level has no effect. Permission to the special <BYPASS> pseudo‑member should be granted only at the ALL access level. Permission may be denied with the NONE access level. Permission granted at any other access level has no effect.
• Administrative functionality for PDSE data sets is the same as PDS data sets.
• Program fetch for execution is exempt from PDS member level protection since this access is already securable through the existing PROGRAM resource class.
• If VLF caching is used for TSO CLIST libraries, PDS member level protection is bypassed for cache‑resident CLISTs when executed under TSO.
• PDS member level protection compliments rather than replaces data set security. To read a PDS member, a user requires both a data set PERMIT allowing access to the data set and a resource PERMIT allowing access to the member.
• Note that any user with ALL authority over a PDS data set can circumvent PDS member level protection by their inherent ability to rename or delete the entire PDS data set.
• Whenever a PDS member is read using an ALIAS name, the true member name is used in all member level validations.
• Renaming a PDS member requires update authority for the old and new member name.
• For speed, a program may issue read multiple PDS members in a single I/O operation when reading or backing‑up a PDS data set. With PDS member level protection active, such operations will correctly generate a resource check for every PDS member accessed. The OEM PDS command for TSO is a common example. When using this TSO command in full‑track mode, member level checks may occur for more than one obvious member name. This is normal in this mode. Use the CONTROL MULTIPLE and CONTROL SINGLE sub-commands of this command to easily enable or disable this mode as desired.
• The DASD restore of an entire PDS data set from a backup or archive will not typically generate PDS member level protection checks for members within the PDS data set being restored. Likewise, an IEHMOVE of an entire PDS will generate PDS member level protection checks for the input PDS data set. However, no member level protection checks will occur for the output data sets until the move completes. In both of these cases, no member level protection occurs because the new data set being created by the restore or move is not recognized as a PDS data set until the file building process is complete.
• When first activated following an IPL, PDS member level protection creates a SCOPE=COMMON OS/390 dataspace to assist processing. The addition of this dataspace may require an adjustment of the MAXCAD=nnn setting within the IEASYSxx member of PARMLIB.