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
