On Friday, 03/06/2009 at 03:31 EST, Bob Bolch <b...@zenoroad.com> wrote: > It?s perfectly fine to discuss the way things ?should be? ?vs- the way things > ?are?, but when a design is more than 20 years old, as in this case, then the > way it works now is, by definition, the way it should be. Making some changes > is just too painful.
I think that we must continually assess the somewhat, uh, "arcane" nature of VM commands. By default, I believe that the ability for UserX to bring UserY onto the system should not be restricted by the particular mechanism used, even though you should be able to exert control over a particular mechanism if desired. A good example is communications. Should I have to protect MSG, WNG, MSGNOH, SMSG, COUPLE, NICDEF, IUCV, VMCF, ADRSPACE PERMIT, shared R/W DCSS, and shared mdisk separately? I don't like that. It's a never-ending quest to discover what new interfaces have been added, and it is a terribly large hammer to swing to enable mandatory access controls in your ESM. I much prefer to be able to protect an activity rather than a command or interface, but we are stuck with history for the nonce. Alan Altmark z/VM Development IBM Endicott
