We do not share a RACF database, but use a copy of the zOS RACF database for
our z/VM system. We make all changes thru the zOS system, and copy/replace the
z/VM RACF database quarterly or as needed. VM security does not change
significantly and the Auditors are happy with this.
=
Jim Olson
Dominion Resource Services, Inc
Senior Software Engineer
OSS - Operating System Support
Phone: (804) 771-3456, Tie Line: 8-736-3456
Email: james.ol...@dom.com
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of Alan Altmark
Sent: Wednesday, January 05, 2011 9:14 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Simple RACF Question - Can the RACF database be shared with z/OS?
On Wednesday, 01/05/2011 at 07:12 EST, Jeff Gribbin
jeff.grib...@gmail.com 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
alan_altm...@us.ibm.com
IBM Endicott
CONFIDENTIALITY NOTICE: This electronic message contains
information which may be legally confidential and/or privileged and
does not in any case represent a firm ENERGY COMMODITY bid or offer
relating thereto which binds the sender without an additional
express written confirmation to that effect. The information is
intended solely for the individual or entity named above and access
by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution, or use of the
contents of this information is prohibited and may be unlawful. If
you have received this electronic transmission in error, please
reply immediately to the sender that you have received the message
in error, and delete it. Thank you.
