How about an "all or nothing" solution, for example:

CP DEFINE/SET VSWITCH switchname .... UNRESTRICTED 

For sites like mine, where virtual switch security is not required, this would 
achieve a single point of definition (NICDEF).

Cheers,

Simon.

----- Original Message -----
From: Alan Altmark [mailto:[EMAIL PROTECTED]
To: [email protected]
Subject: Re: First install of RedHat under z/VM


> On Thursday, 02/09/2006 at 11:49 CET, Rob van der Heij <[EMAIL PROTECTED]>
> wrote:
> > On 2/9/06, Alan Altmark <[EMAIL PROTECTED]> wrote:
> >
> > > It's a design philosophy.  Displaying the access list for a VSWITCH is
> > > difficult if it is a combination of GRANTs plus NICDEFs.  We don't
> want to
> > > search the directory every time someone does a QUERY.  And displaying
> an
> >
> > I figured the design was broken rather than the code, otherwise I
> > would have tried a PMR against it. I fear Chuckie has been smoking the
> > same stuff as Miguel...
> >
> > The need for a QUERY is not obvious to me. What's the benefit of being
> > able to tell what other servers could connect to the same network as
> > you did ? The only purpose now is to check the superfluous GRANT.
> > Network design needs some careful planning anyway and now you have the
> > same people define the same aspect in different places.
> 
> As I say, a different philosophy.  We chose to have an explicit access
> list for guest LANs and VSWITCHes rather than an implicit access list
> based on virtual machine configurations.  And we didn't want to treat a
> dynamic COUPLE any differently than a NICDEF.
> 
> And I happen to think that the directory should be restricted to defining
> virtual machine configurations, with only minimal involvement in access
> rights.  I'd like to be able to implement a remote directory access
> service and still be able to locally administer access rights.
> 
> > Yes, the way I see it when you drop your NIC you can COUPLE that one
> > again to the LAN defined in the directory - only that one. I warned
> > against the risk of DoS with Guest LAN and that was not fixed with the
> > VSWITCH.
> 
> Sorry, Rob, but what does DoS have to do with access rights?
> 
> > Sure, access control through the CP directory (and passwords) is
> > different from using an ESM and it should be.
> 
> I respectfully disagree, Sir Rob.  I believe that the access control model
> should be the same, whether CP or an ESM is in control.  That is: "Here is
> a restricted system widget and the list of user who can access it."
> 
> > With an ESM you can
> > separate functions and manage your access control much better. When
> > the CP directory is the only control, then it is unwise to force the
> > adminstrator to define the same thing in two different places because
> > that causes stale authorisations.
> 
> Agreed.
> 
> The industry tells us that security is Very Important.  Not just the
> security itself, but the management thereof.  We do make an effort to
> maintain the balance between convenience and security, but it ain't easy.
> ("VLAN ANY", anyone?)
> 
> Alan Altmark
> z/VM Development
> IBM Endicott
> 
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> 

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to