If it were done in that other ESM for VM, it would be in its audit file. In the absense of an ESM to inplement it, it would be BAU with no new capability.
Regards, Richard Schuh -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of A. Harry Williams Sent: Saturday, August 25, 2007 5:40 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Sat, 25 Aug 2007 00:20:38 +0200 Rob van der Heij said: >On 8/24/07, Alan Altmark <[EMAIL PROTECTED]> wrote: > >> There are some who believe that the authority to LOGON BY to a user should >> implicitly allow: >> - XAUTOLOG >> - SET SECUSER or OBSERVER >> - SEND (a la class C) >> - FORCE >> - SIGNAL SHUTDOWN > >Put away what you're smoking... Let's get back again to the style >where we come up with the requirements and plea for years to get the >commands in the directory, and you guys code it ... :-) > >I understand the idea that these commands achieve things that you >could do if you would logon to the virtual machine. Sure, but far from >complete: FOR has been suggested, but what about STORE HOST (as long >as the frame holds a page of that virtual machine) and DETACH, and... > >My major concern is auditing. While I trust that the implementation >will take care of auditing in the ESM, it makes it much harder to see >who has been messing with it. Normally when a user tells his server >"suddenly failed" you could scan the PROP logging and see which of the >developers reconnected, and tell him to hit his peer over the head >with it. But when neither of the virtual machines has its console >spooled, you would not be able to tell what happened. Well, that implies a greater need for logging the auditing. The "other system" does that via SMF. In VM, that would be either Accounting records or Monitor records. Based on granularity of controlling how much is logged, and the similarity of what is done for other logging uses on VM, I'd recommend Monitor records. ... > >Rob /ahw
