Some possible uses for RACF exits are:
• Allowing access to a RACF -protected resource when RACF is inactive
• Protecting the user from accidental destruction of data
• Enforcing rules for the content of passwords
• Modifying data set naming conventions
• Ensuring tape protection for tapes without a profile Allowing Access When RACF is Inactive
When RACF is inactive, any attempt to access a protected data set is passed to the RACHECK preprocessing exit. On systems that have always call, this check occurs for all data sets. The exit can determine whether or not to allow the access to proceed. If, for example, you want to allow one or more specific users to perform recovery operations, the exit must select them. (If RACF is inactive, the normal privileges of OPERATIONS cannot be used because the RACF data set may not be available to verify that a user is so authorized.) You should consider whether userids or batch jobnames authorized by the exits when RACF is inactive should also be allowed to use the system if RACF is running normally.
If the RACHECK preprocessing exit routine neither grants nor denies access to the data set, RACF failsoft processing may prompt the operator.
Protecting the User's Resources from the User
Users can accidentally delete their own data. Suppose, for example, that a user wishes to delete a library member, but forgets to include the member name in the command. The user issues:
DELETE USER. LIB instead of
DELETE USER.LIB(progname)
With ALTER authority to USER.LIB, the result is the loss of the entire library.
To delete a member requires only UPDATE authority, whereas deletion of the whole library requires ALTER. By default, the creator of a data set (a library is only a special use of a data set) automatically has ALTER authority to it.
Therefore, the user is susceptible to this exposure.
For group data sets (libraries), the creator is in the access list explicitly and can therefore take positive steps to reduce his own authority to UPDATE. The creator is then unable to delete the group data set accidentally. When the creator really does want to delete it, then, still being the owner of the data set, he can restore his ALTER authority using the PERMIT command.
While this is very simple for group data sets, user data sets do not have their creators in the access list. The creator has ALTER authority by virtue of the
Chapter 7. RACF Installation Exits 7-11
naming convention (the high-level qualifier and userid match). There is, therefore, no userid for the creator to remove, and his data is still vulnerable to his own errors.
To provide the same facility for user data sets, you must use the RACF exits. In the RACHECK exit, you can determine if the user is seeking to scratch one of his own data sets. Under these circumstances the exit can invalidate access with the naming convention (by blanking out the QUALIFIER field and allowing access only as specified in the access list). When a user really wants to delete the entire data set, the user can authorize himself explicitly because he is the owner.
Password Quality Control
One of the main objections to the use of passwords generated and maintained by tIie user is that the passwords chosen might readily be guessed. User education is one way to try to resolve the problem. An alternative is to use the system to validate that the passwords selected are suitable.
Whenever a user enters the system, RACF invokes the RACINIT function. At this time the user is able (or might be forced) to change passwords. The installation can devise whatever tests it wishes in order to ensure that the password supplied meets the required standard.
RACF gives you the ability to specify password content rules with the
SETROPTS command. You can make additional checks using the exit routines.
Because the new password exit is called by both RACINIT and the PASSWORD command, this exit is a good place to make the additional checks on new
passwords.
For example with the SETROPTS command, you might ensure that the password is more than six characters or that it contains an alphanumeric mix. With an exit, more complex tests might disallow names, months, userids, and group names, or detect trivial usage of alphanumeric mixes such as JAN85 and FEB85.
Modifying Data Set Naming Conventions
If the required processing is too complex to be handled by using the ICHNCONV macro, you can use exit routines to modify data set naming conventions. A naming convention routine or table should be able to perform the following functions:
• Conversion of a user's real data set name into a format acceptable to RACF (the high-level qualifier is a userid or group name)
• Conversion of the internal RACF format back to the user's real data set name for display purposes (ICHUTIOO, and LISTDSD and SEARCH after a profile is located but before it is displayed)
• Identification of a userid or group name to be used for authority checking
• Optionally, enforce other restrictions on data set names (format and content) on define requests (ADDSD, RACDEF DEFINE/RENAME)
• When running with more than one input data set, the ICHUT400 utility copies from the lowest number INDDn data set
Some of the exits that you could use for modifying data set naming conventions are:
• ICHCNXOO - Command preprocessing exit
• ICHCCXOO - Command preprocessing exit
• ICHRDXOI - RACDEF preprocessing exit
• ICHRDX02 - RACDEF postprocessing exit
• ICHRLXO I - RACLIST pre/postprocessing exit
• ICHRLX02 - RACLIST selection exit
• ICHRFXOI - FRACHECK preprocessing exit
• ICHRFX02 - FRACHECK postprocessing exit
Chapter 7. RACF Installation Exits