z/OS security with RACF: user, group, and dataset profiles, and why agents need least privilege

What it is

The System Authorization Facility (SAF) is the interface z/OS components call to ask "is this user allowed to do this?"; RACF (Resource Access Control Facility, part of z/OS Security Server) is the security product most commonly plugged in behind that interface to answer the question, though other SAF-compliant products exist. RACF organizes access around profiles: a user profile per user ID, group profiles for collections of users, and resource profiles — including dataset profiles — that name what is protected and who may access it at what level (read, update, alter, and so on).

LISTUSER userid displays a user profile's attributes and connected groups; LISTDSD lists dataset profiles, including generic profiles that cover a whole naming pattern rather than one exact dataset name. Access is granted with PERMIT once a profile exists (created with ADDSD for datasets, RDEFINE for general resources): for example, PERMIT profile-name CLASS(CSFSERV) ID(groupID) ACCESS(READ) grants read access on a defined resource to a group ID, which is usually preferable to permitting individual user IDs one at a time. In a class kept in storage (RACLISTed, as CSFSERV usually is), changes take effect only after SETROPTS RACLIST(class) REFRESH; changed generic dataset profiles may need SETROPTS GENERIC(DATASET) REFRESH for already-running work.

IBM's own guidance is explicit that RACF's list commands — LISTUSER, LISTDSD, LISTGROUP, RLIST — are designed to be issued by a person and read by a person; their output format is not a supported programming interface, is not guaranteed stable across releases, and IBM does not support parsing that output from a program. Programs should instead use the documented interfaces IBM names: the output file of the database unload utility IRRDBU00, RACROUTE REQUEST=EXTRACT, or ICHEINTY.

Why it matters

An automation agent is exactly the kind of actor RACF administration should constrain tightly: it should authenticate as its own dedicated, narrowly scoped user ID with only the access its task requires, not reuse a broadly privileged administrator ID, and any script that parses LISTUSER/LISTDSD text is relying on an interface IBM has stated is not meant for programs.

How to apply

• Provision a distinct RACF user ID per automated task or agent, connected to the minimum groups, permitted the minimum resource access, and without the system-wide SPECIAL, OPERATIONS or AUDITOR attributes.
• Grant access through group profiles and PERMIT rather than permitting individual IDs, so access review happens at the group level.
• Prefer a supported reporting interface over parsing LISTUSER/LISTDSD output when a program needs the data.
• Review dataset and general-resource profiles periodically for ACCESS levels broader than the task needs (ALTER where READ would do, for instance).

Pitfalls

• Running automation under a shared or highly privileged TSO ID "to avoid permission problems," which defeats auditability and violates least privilege.
• Treating LISTUSER * or similarly unbounded listings as a normal automation call; IBM notes such output can exhaust address-space storage and points to IRRDBU00 instead.