On Tue, 29 Dec 2015 12:18:40 -0600, John McKown wrote: >> >> su other >> oedit file >> >> ... the ISPF editor is invoked not under the other user ID, but under the ID >> that issued the OMVS command. >> > >Which makes "sense" > No.
>if you think about what the "oedit" command actually does. > The user should be spared such mental gymnastics. >Think of the OMVS command as doing a fork() to start a new UNIX >process. Which is what it does. But the "oedit" command is just a >communications tool to send a file name back to the "parent" process (ISPF) >telling it to do an ISPF edit on the given UNIX file. > Bad design. At best half-baked. >...The "oedit" command >then "waits" for the ISPF process to tell it to resume. So the editing is >actually being done in the user's TSO address space. That's why you can >SWAP to another ISPF screen while doing an "oedit". The UNIX / OMVS process >is asleep during this time. > >To me, this is conceptually similar to running a stored procedure in some >data bases. The user requests the stored procedure, but it runs using the >UNIX identity of the RDBMS server, not the user. At least, that's what >somebody told me. I don't remember which RDBMS they were talking about. > That's almost the opposite of the OMVS behavior, in whch oedit runs under the ID not of the immediate caller, but of one somewhere up the chain. In contrast, the stored procedure runs under the UNIX ID of the RDBMS server, its immediate caller, not of the originating job. Doesn't this cause security exposures, even as "sudo vi" is dangerous if the user is allowed to :sh to an untrusted script? I suppose it depends on what stored procedures are allowed to do. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
