We have been using class V for years to allow the TPF guests to be able to find an available Security Module and ATTACH it to themselves. They do not get DETACH because then they could wreak havoc by detaching from other guests and from SYSTEM. Class V also gets the ability to use class B QUERY commands. Nobody outside the VM Systems group and the operators has either class B or C. The normal is class G for those who are not set up for TPF testing; GV for those who are. The only MVS types who even have ids on the system are those who must deal with the hardware configuration. Giving them anything but GV would make me nervous as they may log on once or twice in a year. Their VM skills are not finely honed.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark > Sent: Wednesday, July 14, 2010 2:01 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Devices OFFLINE at IPL > > On Wednesday, 07/14/2010 at 02:03 EDT, Gregg > <reed.gr...@gmail.com> wrote: > > So if it can't be controlled at the LParr, then priv class > C(B too?) > > needs to be locked down to the few MVS security folk trust. > > - Never give privilege class C to anyone who is not a trained > AND trusted z/VM systems programmer. > - Never give privilege class B to anyone just so they can > issue the ATTACH and VARY commands. Instead, define them as > privclass BQ and give your > trusted MVS people privclass GQ. (e.g. MODIFY COMMAND > ATTACH PRIVCLASS > BQ) > > Alan Altmark > z/VM Development > IBM Endicott >
