Reminds me of a system modification we had back in the day, at another company, that the SNA Staff could LOGON to VMVTAM but could not issue LOGOFF.
-----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 12:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Monday, 08/27/2007 at 09:20 EDT, Rob van der Heij <[EMAIL PROTECTED]> wrote: > Your scenario would only break when Alan had proposed "reverse > inheritance" or "sideways inheritance" of privileges (the person who > logged on to TESTABC could also have chosen to logon to TCPMAINT, so > let's now give TESTABC the authorisation that TCPMAINT would have > had). Rob, I did not propose to give TESTABC the authorization that TCPMAINT would have/ Rather, I proposed that TESTABC could, for example: - XAUTOLOG TCPMAINT because the user could just bring up another terminal session and LOGON TCPMAINT/DISC - FORCE TCPMAINT because the user could LOGON TCPMAINT/LOGOFF - SEND TCPMAINT because the user could LOGON TCPMAINT/SET SECUSER TESTABC/DISC or just LOGON TCPMAINT and start issuing commands - SIGNAL SHUTDOWN TCPMAINT because the user could LOGON TCPMAINT/SIGNAL SHUTDOWN/DISC > A somewhat similar problem is with the altuser implementation when the > target gets the combined authorisation of the worker machine and the > owner of the job. That is only the default RACF implementation and is controlled by a RACF exit; CP does not redrive the authorization. In fact, the Common Criteria evaluated configuration requires that this exit be removed. It's on the To Do list to allow the RACF admin to identify specific users who are, in fact, batch machines that need that functionality. Alan Altmark z/VM Development IBM Endicott -------------------------------------------------------- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. --------------------------------------------------------
