z/OS Security Server RACF Security Administrator's Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Protecting program libraries

z/OS Security Server RACF Security Administrator's Guide
SA23-2289-00

Program libraries can be for public use or for private (limited) use. You designate a set of libraries as public by placing the libraries in the system link list concatenation, which is SYS1.LINKLIB and any program libraries concatenated to SYS1.LINKLIB through the use of the LNKLSTxx member of SYS1.PARMLIB.

A private load library is one that is not in the system link list or one that is explicitly accessed as a private library (even if in the system link list) through:
  • A JOBLIB, STEPLIB DD, or other form of tasklib
  • A TSO/E CALL command of the form:
    CALL 'library_name(program_name)'
For programs in a system link list library, the user generally does not need access to the library itself, and you could grant the user the following access authorities:
  • READ: if the user is authorized to examine the content of programs or copying programs from the library
  • NONE: if the user is not authorized to examine the content of programs or copy them.
Note: Users do not need access to libraries in the link list in order to run programs from them if they allow the system to load their programs from the link list itself. However, users need access to any library referenced as a private library (for example, using a JOBLIB, STEPLIB, or the TSO/E CALL 'library-name(program_name)' command). Even if you have users issuing the TSO/E CALL command, you can still grant NONE authority to the library if they use a different form of the command, CALL *(program_name). This command instructs the system to find the program in the LNKLIST or link-pack area without specifically accessing the library itself. If the users cannot use that form of CALL, or need to reference the library as part of JOBLIB or STEPLIB, you must treat the library as a private library if you do not want the user inspecting the library contents.

To protect a private library from a user viewing its content or copying programs from it, grant the user EXECUTE authority to the library itself through the DATASET profile that protects the library. For example, if you have a library named 'AAA.LIBRARY1', you could issue either of the following examples:

Examples:
  1. ADDSD  'AAA.LIBRARY1' UACC(EXECUTE) 
  2. ADDSD  'AAA.LIBRARY1' UACC(NONE) 
    PERMIT 'AAA.LIBRARY1' ID(*) ACCESS(EXECUTE)

When EXECUTE authority is the highest access level that users have to a private load library, the library is known as an execute-controlled library. If some users have EXECUTE authority, and some have READ authority, the library is execute-controlled for some users and not for others.

Guideline: In general, grant READ access rather than EXECUTE unless you have a strong need to prevent users from viewing the contents of a program library. Using EXECUTE requires that you keep the users' program execution environments clean, and requires more administrative effort and restrictions on how the users can access programs from the libraries.

Restriction: If you want EXECUTE restrictions to apply to a user who has OPERATIONS authority, you must explicitly PERMIT that user or one of the user's groups to the DATASET profile with EXECUTE authority. UACC(EXECUTE) or ID(*) ACCESS(EXECUTE) does not make a library execute-controlled for a user with OPERATIONS authority.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014