Security’s Multi-Purpose FACILITY Classes

by Robert S. Hansel , Mark S. Hahn
May 1, 2006

Which RACF class has grown from housing a few profiles to housing more than 100? Which class has grown into a major player in the control of many key z/OS services? It also has recently grown from a single class into one with a companion member-grouping class pair. You’d be correct if you answered the FACILITY class. But what services are taking advantage of this long-standing class and why has a new member/grouping class pair been created?

This article explains the base concepts and use of the FACILITY class and its new companion classes, XFACILIT and GXFACILI. These new classes were introduced in z/OS 1.7 and can be rolled back to z/OS 1.4 with APAR OA10774. Currently, only the IBM Health Checker for z/OS uses XFACILIT. While we’ll discuss the FACILITY class from a RACF perspective, the information provided applies to other mainframe security products that respond to RACROUTE calls to the System Authorization Facility (SAF). Instead of the FACILITY class, CAACF2 knows this as FAC and CA-Top Secret uses IBM-FAC.

Early in RACF’s evolution, the developers recognized a need for a general-purpose resource class available to any system service with too few resources needing protection to justify a separate class. This was back when the maximum number of resource classes was relatively small and implementation of an additional class required an Initial Program Load (IPL), a constraint that has only recently been lifted with the Dynamic CDT introduced in z/OS 1.6. The FACILITY class was born in response to these original requirements.

Over the years, an increasing number of system services used the FACILITY class to protect their growing list of functions. From its humble beginning of just a few system services and a handful of their related resources, the FACILITY class has grown to dozens of system services and more than 100 different resources. Many third-party products also have chosen to use the FACILITY class because it was readily available in all MVS, OS/390 and z/OS systems, and required no modification to the RACF tables.

FACILITY Classes Characteristics

The FACILITY classes and their characteristics are defined in the RACF Class Descriptor Table (CDT). Figure 1 describes a few of the more pertinent characteristics.

The FACILITY class maximum of 39 characters is quite limiting when creating descriptive names for newer resources. This RACF limitation, which wasn’t lifted until the restructured database in RACF 1.9, has been addressed in the new XFACILIT and GXFACILI classes, where resource names can be up to 246 characters. This is needed by the IBM Health Checker for z/OS, since it addresses the increasingly complex system environment by including such information as the system name, owner name and function in the resource name for authorization. Two such examples appear in Figure 2.

Resource Naming Conventions