On Sat, 18 Sep 2010 10:00:33 -0400, Michel Beaulieu <beaulieumic...@live. ca> wrote:
> >Hello, > >It is so interesting that people need to expand so much on "why" before discussing the "how". > >In Unix/Linux, we have the "su" command that let someone take another id entification >for a while and when done, just exit and return to the normal userid. >Can we do something like that in z/VM? You have hit upon one of the fundamental differences between Unix and z/V M. Unix is process- oriented. z/VM is virtual machine oriented. In Unix you can spawn another process which (courtesy of su and other mechanisms) has greater privileges than the original proc ess. In z/VM, virtual machines are hermetically sealed from one another, unless the system prog rammer does something to authorize breaking through, or unless you give a virtual mac hine non-class-G privileges. You cannot "spawn" another virtual machine. (You can AUTOLOG it though, given authorization, but you have in no way taken over its privileges.) This di fference also explains why you can login to the same userid multiple times in Unix (different proces ses) but you cannot do that in z/VM (only one virtual machine). It also explains why there is no SSH server on z/VM, since that would require spawning other virtual machines. IBM built into CMS something called OpenEdition which is a Posix subset, but not a full Unix. In particular, it does not support the full Posix 'fork' command. IBM went a head and upgraded z/OS to a fully Unix-compatible (but EBCDIC) Unix System Service, but did not do that for z/VM. It would have required significant changes to the CP component (the hypervis or) of z/VM. Whether or not that was a correct decision back then, I doubt it will ever happen no w. There are many ways to do what you want to do in z/VM. WAKEUP is simply t he simplest way to do it -- a built-in CMS command around which you can build an SVM. Unix does many things with daemons, so it should not be such a foreign idea to Unix folks. Similar t hings could be done directly in assembler -- from our viewpoint, it's easier to work in REXX. Another way is to use the logical device support facility built into z/VM . The logical device support facility allows a program to create a logical terminal, which can then lo g on, just like a real terminal, enter passwords, issue commands, etc. I would do that using the MPVM component of the PVM program product. But PVM is a non-free program product. There are free downloadable programs in the z/VM library that implement logical device support, and M IGHT allow automaton (I have not tried) or you could again write code in assembler. Of course, to do this, you would need to know the userid and password of the machine you want to logon to. And only one user could do it at a time. As someone else pointed out, there is diagnose D4. The manual says: DIAGNOSE code X'D4' is used by a master virtual machine when scheduling w ork on one of its worker virtual machines on behalf of an end user. The end user's user ID is considered to be the alternate user ID. I don't see how that really provides a way to increase the authority of a virtual machine. If you can do that, then, I'd think that would be a hole in z/VM's underlying securi ty big enough to drive a truck through. (And therefore APARable.) Then there are APPC/VM and CPI Communications. These are rather more comp lex, but you could read up on them. Right, more WHY instead of HOW. But all that stuff I mentioned is documen ted, if you want to try it. Alan Ackerman
