For your temporary solution before you move to 5.3 - you can add the Class A SET RESERVED to an unused priv class, for example, R (also keeping it as Class A) and add this priv class to your Linux guests. In the PROFILE EXEC, after you execute the SET RESERVED command, you execute: CP SET PRIVCLASS * -R CP SET PRIVCLASS * LOCK (this assumes you have SET PRIVCLASS enabled in the system config!) Now, a root user on Linux can't change the reserved setting without first undoing the lock, and SET PRIVCLASS * UNLOCK is not allowed when the user is disconnected (and you get a prompt from CP on the console when a terminal is connected.)
Certainly not bulletproof, and the COMMAND directory entry is the best when you get 5.3 going, but better than just leaving the command available.. On Jan 17, 2008 1:44 PM, Morris, Kevin J. (RET-DAY) <[EMAIL PROTECTED]> wrote: > Hi David. Thanks for the response. > Yes, I have actually implemented that same paradigm of a common PROFILE > EXEC on a R/O that executes <userid> EXEC as well. The only problem is > that all of our linux guests are PRIVCLASS G, and the SET RESERVED > command is PRIVCLASS A. I don't want to give the linux guests > PRIVCLASS A for obvious reasons, and I'm not sure that I'm comfortible > with changing SET RESERVED to PRIVCLASS G. Perhaps I will change the > command to G as a temporary solution until we upgrade to 5.3 and have > access to the COMMAND statement in the user directory. > > Thanks for the help. > -Kevin -- Bruce Hayden Linux on System z Advanced Technical Support Endicott, NY ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
