On Friday, 03/06/2009 at 12:47 EST, "Schuh, Richard" <rsc...@visa.com> wrote: > Ah, but I do have a point. The REJECT * LOGON does not allow the same type of > override that is allowed by other rules. In this, there is inconsistency. > Actually, I have two points. The second is that, if LOGON is viewed as a > process that is being controlled by the rule, then REJECT * LOGON should > control all forms of logging the user on. After all, the same code is used to > create the virtual machine.
I was given 50 lashes with a wet noodle here when I previously proposed that if you have LOGON BY authority to a user you should be able to - LOGON to the user - XAUTOLOG the user - Use FOR - Use SEND (even if not the secuser) - be the SECUSER or OBSERVER Except that I would not allow SET SECUSER/OBSERVER, SEND or FOR if the user was logged on or someone else is the secuser. Unlike the privileged versions of those commands, serial access to the user ID would be enforced. Alan Altmark z/VM Development IBM Endicott
