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


Profiles in the CDT class

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

The task of administering profiles in the CDT class can be done by you, the security administrator, but because changes in the dynamic CDT can affect resource classes in the static CDT and impact your entire RACF® system, you are advised to consult with your system programmer before making changes. Then, you can delegate the task of administering dynamic CDT entries to the system programmer by granting class authority (CLAUTH) and field-level access to the CDTINFO profile segments.

Example:
ALTUSER SYSPROG CLAUTH(CDT) 
RDEFINE FIELD CDT.CDTINFO.* UACC(NONE)
PERMIT CDT.CDTINFO.* CLASS(FIELD) ID(SYSPROG) ACCESS(UPDATE)
See Field-level access checking for the steps to enable field authority.

When you define class name entries in the dynamic CDT, you create profiles in the CDT class. These profiles define the dynamic CDT entries themselves, rather than protect resources in the classes they define. In other words, granting READ access to the profiles in the CDT class allows the user, for example, a system programmer, to view the dynamic CDT class entries. Granting ALTER access to these profiles allows the user to change the access list or delete class name entries. Therefore, you should control ALTER access carefully. In addition, having access to a CDT profile does not grant access to profiles in the resource class defined by that CDT entry.

The name of the profile you create in the CDT class is the name of your new class in the dynamic CDT. The syntax rules for the CDT profile name are as follows:

Rules:
  1. The profile name must be 1 - 8 characters, consisting of the following:
    A - Z
     
    0 - 9
     
    #
    (X'7B')
    @
    (X'7C')
    $
    (X'5B')
  2. You must include at least one character from the following:
    0 - 9
     
    #
    (X'7B')
    @
    (X'7C')
    $
    (X'5B')
Rule 2 ensures that class names you define in the dynamic CDT do not conflict with class names supplied by IBM® in ICHRRCDX. If you do not follow this rule, a warning message is issued for the RDEFINE or RALTER command when you define or update a profile in the CDT class; however, the profile is still defined or updated. You can use the RDELETE command to delete the profile before you issue the SETROPTS RACLIST(CDT) command to build or refresh the dynamic CDT. If you do not delete the profile and subsequently issue the SETROPTS RACLIST(CDT) command, another warning message is issued but the class can be defined and activated if there are no other errors.

Restriction: If you do not follow Rule 2 and if, in the future, IBM supplies a class using the same name you defined, the IBM class will be used instead of your class, and the results will be unpredictable.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014