Securing System Resources › Securing Resources That can Be caca › Securing Programs

Securing Programs

About Programs

When you secure programs, you can control who can execute programs maintained in an operating system load library.

Until you secure programs, any user can execute a program in the operating system load library.

How to Secure Programs

To secure programs internally, include an entry in the SRTT:

#SECRTT    TYPE=ENTRY,                                        X
      RESTYPE=SPGM,                                           X
      SECBY=INTERNAL

To secure programs externally, include an entry in the SRTT:

#SECRTT    TYPE=ENTRY,                                        X
      RESTYPE=SPGM,                                           X
      SECBY=EXTERNAL,                                         X
      Additional parameters required

Whether to Secure Programs

If you secure programs, only an authorized user can execute a user-mode program, including any CA IDMS user-mode program. Therefore, you should carefully weigh the requirements for administering program security.

For example, if you secure programs externally, you must identify to the external system all user-mode programs supplied by CA IDMS and site-specific application programs that users need to execute and specify the rules for securing these programs.

If you secure programs internally, you can take advantage of categories, wildcards, and groups to simplify this process.

Note: To identify CA IDMS user-mode programs, view the DLODSECR member of the installation source library.

Alternative to Program Security

The purpose of securing programs is to control access to data. An approach to protecting data at the program level that may be easier to administer is to secure databases or database occurrences:

• For program access to non-SQL defined databases, you categorize run units and grant execution privilege on the categories. The task of categorizing run units is simplified by the inclusion of database name and subschema name and program name in the run unit identifier. This approach is comparable to program registration in Release 10.2.

  Note: For run unit information about CA IDMS user-mode programs, view the DLODSECR member of the installation source library.

• For program access to SQL-defined databases, you grant applicable privileges on access modules.

Program Occurrence Overrides

You can specify occurrence overrides in the SRTT for the SPGM resource type. If you secure programs externally, you must add to the SRTT an occurrence override to unsecure the signon program (RHDCSNON). Without this override, any attempt to signon will fail.

In this example, security for programs is external, but occurrence overrides makes RHDCSNON and RHDCBYE unsecured:

#SECRTT    TYPE=ENTRY,                                        X
      RESTYPE=SPGM,                                           X
      SECBY=EXTERNAL,                                         X
      Additional parameters required

#SECRTT    TYPE=OCCURRENCE,                                   X
      RESTYPE=SPGM,                                           X
      RESNAME='RHDCSNON',                                     X
      SECBY=OFF

#SECRTT    TYPE=OCCURRENCE,                                   X
      RESTYPE=SPGM,                                           X
      RESNAME='RHDCBYE',                                      X
      SECBY=OFF

Note: For more information, see the following sections:

• #SECRTT, in the chapter "Syntax for Assembler Macros"
• CREATE RESOURCE, in the chapter "Syntax for Securing System Resources"
• Category Security Processing, in the chapter "Securing System Resources"