Well, *anyone* is a pretty small crowd. No one gets an VM id except the vm sysprogs and a few who need to look at ESAMON. If I were super-paranoid, we could remove the define nic and/or couple from class g and put them in a privclass that only a linux got. It would be interesting to see those folks *try* to do something with the vswitch nic they defined :)
Unless the *anyone* is perhaps someone who has gotten root on a linux... But then, they've already got an interface into the vswitch... So, unrestricted VSWITCH and implicit authorization - I don't care one way or the other. Which requirement would be easier to get through? Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, December 07, 2007 11:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VSWITCH bug ? On Friday, 12/07/2007 at 02:31 EST, Marcy Cortes <[EMAIL PROTECTED]> wrote: > Ding ding! We have a winner! > Thanks Phil (yet again). > The explicit couple in another COMMAND solved that. > (but yeah, in my copious spare time, maybe I'll open a unrestricted > vswitch requirement). BTW, an unrestricted VSWITCH would mean anyone could couple to it at any time. If you still want a restricted VSWITCH, but with implicit authorization when specified on NICDEF in the directory (sans ESM), that's a different requirement. Alan Altmark z/VM Development IBM Endicott
