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. Oh, and how about RACF restrictions that apply to the LOGON (like terminal or time) ? How would that apply to the proposed commands? If you really think this is useful, then use different profiles in the surrogate class (e.g. MAGICBY.<target>) so that an installation can decide which end users are able to use this. Rob
