On Wednesday, 01/05/2011 at 07:12 EST, Jeff Gribbin <[email protected]> wrote: > I've not used RACF on VM for a few decades and I believed that, as z/OS > advanced, there came a time when it was no longer possible to share a RACF > database between a z/VM system and a z/OS system. I'm sure that this belief > was based upon statements made by people that I trust, plus my own > understanding of the disparity between RACF development on z/OS and its > development on z/VM, but ...
I am the one who has suggested publicly that just because you *can* share, it does not follow that you *should* share. As the documentation says, you CAN share the database with z/OS. However, the database MUST be protected by Reserve/Release. That means that in a SYSPLEX, GRS on z/OS must be configured to allow ENQs issued for the RACF databases to use Reserve. And, for most, that rules out a sysplex, which is taking explicit advantage of GRS rings/stars. As you suggest, RACF/MVS and RACF/VM are different products with different development streams targeted to different audiences, all managed by different organizations. While the two groups are reasonably coupled from a Design point of view (we don't want to step on each others' toes), they march to the beat of different drummers. A few short years ago the VM side accidentally shifted some bytes in a database control field mapping macro, causing classes on z/OS and older versions of RACF/VM to be mysteriously turned off. We found the bug fairly quickly and resolved the issue, but the APAR wasn't pretty, requiring a utility to repair the database. >From an admin point of view, some of the commands work differently on z/VM than on z/OS. Example: On z/VM you can define a user with no password and no password phrase, or just a password phrase. You can't do that on z/OS (the same way). >From a security point of view, I don't like db sharing outside of a cluster. The local SMF logs do not (cannot) record changes made by other systems, even though they affect the local system. Further, you are giving the "alien" system access to, and control of, secrets it does not need to posses. If the alien system is hacked, the db is exposed. Likewise, if VM is hacked, the z/OS system is vulnerable. (No need to crack a password, just change it.) And because of the logging, you will never know it happened. I'd like to see z/OS and z/VM customers (e.g. via zBLC and Requirements) put pressure both RACFs to bring RRSF to VM or to enhance the LDAP interface so that LDAP replication and/or IBM Tivoli Directory Integrator can be used to propagate profiles and database settings (SETROPTS) among an arbitrary set of RACF instances. A single point of management for RACF (VM+MVS) is a desirable thing - I get it. But sharing the database is a case of the tail wagging the dog. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 [email protected] IBM Endicott
