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
Re: Ops privs (was Re: MAINTENANCE)
Nick Laflamme [EMAIL PROTECTED] wrote: Fortunately, IBM makes it easy for us to define new command classes so we can do it our way. If I were feeling demanding, I might whine about IBM (and other vendors) listing command classes they want instead of commands (and DIAGs) they want, but I'm not, so :-) Some of us had it beaten into our heads early (by having been IN shops with commands moved around among classes) to document Requires Class A for CP FORCE, XAUTOLOG, and SHUTDOWN and like'a'dat, but yeah, I've seen other vendors who don't do so well... ...phsiii
Re: Ops privs
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 Thoughts? My first thought was, Sure, of course. My second thought was, Well...maybe, but I bet some of the tight-security folks wouldn't like it. My third thought was, Just make the controlling user SECUSER...but then I realized how painful that is for the controlling user to get any work done, as random console output appears from the n controllees. My fourth and final thought (ON THIS TOPIC) was How about another card -- CONTROL user1 user2 user3... usern that would allow all of these for user1 through usern? As z/VM evolves from an end-user environment to a guest host environment (evolves? reverts?), things like this make more and more sense. And would certainly continue the tradition of native, granular control, which some Other Operating Systems don't seem to get... ...phsiii
Re: Ops privs
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Phil Smith III Sent: Saturday, August 25, 2007 12:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs My fourth and final thought (ON THIS TOPIC) was How about another card -- CONTROL user1 user2 user3... usern that would allow all of these for user1 through usern? As z/VM evolves from an end-user environment to a guest host environment (evolves? reverts?), things like this make more and more sense. And would certainly continue the tradition of native, granular control, which some Other Operating Systems don't seem to get... ...phsiii I think maybe it was Rob who suggested ... Make them directory statements like the rest ... AUTOLOG, LNKNOPAS, etc.. I suppose the assumption is that CP would bow to the ESM, the ESM support the statement(s) (or not) ... JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED]
