Access Rules for Execute-Only CMS Files

Maintaining Access Rules with the ACF Command › Access Rule Components › Access Rule Entries › Access Rules for Execute-Only CMS Files

Access Rules for Execute-Only CMS Files

Execute is one of the access parameters of a CA ACF2 for VM access rule. As with READ or WRITE access, you can define execute access as ALLOW (A), LOG (L), or PREVENT (P). Execute‑only access means that specified users can only execute the file. They cannot read or write to the file. Execute‑only access prevents users from reading, copying, or issuing traces for sensitive files, programs, modules, and execs.

You can define execute‑only access for a CMS file when a rule prevents or logs read access attempts and allows or logs execute accesses. The following rule entries define execute‑only environments:

 V0191.MYFILE1:module.UID(*) READ(P) EXEC(A)
 V0191.MYFILE2:module.UID(*) READ(P) EXEC(L)
 V0191.MYFILE3:module.UID(*) READ(L) EXEC(A)
 V0191.MYFILE4:module.UID(*) READ(L) EXEC(L)

You must meet two conditions before you can create execute loggings: CMS files must have the EXEC(L) or EXEC(P) access environments in the rule, and CMS files with EXEC(P) or EXEC(L) access environments cannot reside on the CMS 190 S‑disk. CA ACF2 for VM does not perform execute access validation for files with READ(A) access. The second and fourth rules in the previously displayed example create SMF loggings.

To improve performance, no execute‑only loggings are created for any modules on the S‑disk.

Writing Execute-Only Rules

This example is similar to the one in the previous section. TLCAMS has allowed links to her 0191 minidisk through a minidisk rule:

$KEY(TLCAMS)
 V0191.VOLUME UID(APP‑) READ(A)

To log READ access and allow execute‑only access to a particular module on that minidisk, she must write an additional rule entry:

$KEY(TLCAMS)
 V0191.VOLUME UID(APP‑) READ(A)
 V0191.MYFILE:module.UID(APP‑) READ(L) EXEC(A)

Now, all users whose UIDs match the APP- mask are logged for READ access and allowed EXEC access to the MYFILE:module.file TLCAMS owns that resides on the 0191 minidisk.

What if TLCAMS wants to let one particular applications programmer (TLCPJM) execute the MODULE but prevent read access? She must write an additional rule entry to prevent this more specific access.

$KEY(TLCAMS)
 V0191.VOLUME UID(APP‑) READ(A)
 V0191.MYFILE:module.UID(APPTLCPJM) READ(P) EXEC(A)
 V0191.MYFILE:module.UID(APP‑) READ(L) EXEC(A)

This new rule entry lets APPTLCPJM execute TLCAMS's CMS module MYFILE:module.that resides on the 0191 minidisk, but prevents APPTLCPJM from reading the module.

Performing Execute Validations

CA ACF2 for VM performs execute‑only validations in all the following circumstances, providing that the access rule specifies READ(P) or READ(L). (CA ACF2 for VM does not create loggings for modules that reside on the
S‑disk.):

Initiating a module
Initiating an exec
Initiating an XEDIT macro
Loading a nucleus extension with the CMS NUCXLOAD command
Loading an exec or XEDIT macro with the CMS EXECLOAD command.

As long as the execute‑only file remains in storage, all storage displays initiated through the CP DISPLAY, DUMP, and VMDUMP commands are suppressed unless the user has the SECURITY or DUMPAUTH privilege. Additionally, all traces invoked through the PER and TRACE commands and all EXEC traces are suppressed unless the user has the SECURITY or DUMPAUTH privilege.
CA ACF2 for VM does not perform execute‑only validations on TEXT files.

There are a small number of CMS module files that call DMSRLD at execution time to read a second copy of the module into virtual storage. When those modules are initiated, CA ACF2 for VM does an execute validation. After these modules begin executing, the call to DMSRLD causes CA ACF2 for VM to perform a read validation. Therefore, you may need to allow users to have read access to those particular modules so these modules can execute properly. The WAKEUP, FILESTAK, and FILESTCK modules are known to make this type of call to DMSRLD.

Clearing Storage

When the execute‑only file is dropped from storage, CA ACF2 for VM clears the storage to binary zeros when:

Terminating an execute‑only module
Terminating an execute‑only exec that was not explicitly loaded through EXECLOAD
Terminating an execute‑only XEDIT macro that was not explicitly loaded through EXECLOAD
Dropping a previously loaded execute‑only exec or XEDIT macro with EXECDROP
Dropping a previously loaded execute‑only nucleus extension with NUCXDROP.

All outstanding execute‑only files must be dropped from storage before a user can reinitiate a display or trace. For information on using CP commands for execute‑only files, see the Systems Programmer Guide.