On Sat, 2 Nov 2019 23:03:16 +0000, Jon Perryman wrote:
> 
>> Doesn't any program object invoked by // EXEC PGM= execute in the initiator's
>> address space?  
>
>Sorry. I forgot to say EXEC PGM=AOPBATCH is safe. 
>
That might be true if AOPBATCH were installed with AC=0
in an authorized library.

>> Is there the same exposure for any user-coded program that uses LINK or 
>> ATTACH?  
>
>The AOPBATCH exposure is with LINK or ATTACH. For example, calling it from 
>ISPF exposes everything running in that ISPF session. TSO region size tends to 
>be smaller than dubbed processes. Unix programs tend to consume lots of 
>storage. Things like MALLOC do not abend and program's don't always check for 
>success. Using & in scripts could leave forked processes running. I could come 
>up with more 
>
>Address space sharing has rules and it's been far too long for me to remember 
>the specifics. Those rules could easily have changed since I last used it. 
>BPXBATCH always ensured you worked in a safe environment without the need to 
>understand those rules.
>
>> How does the exposure compare with BPX1SPN BPX_SHAREAS=MUST /bin/sh?
>
>It's been a long time. If I remember correctly, it has the exposure. What 
>makes this acceptable is that you know there are risks but willing to accept 
>those risks.
>
How does this interact with the z/OS Statement of Integrity?  If
an ISPF macro invokes BPX1SPN BPX_SHAREAS=MUST /bin/sh,
only IBM code is involved and SoI applies.  SoI has no "willing
to accept" loophole.

Is AOPBATCH an IBM product?  If not, SoI applies if it's installed
only in non-authorized libraries.

COZBATCH is not an IBM product so SoI applies if it's installed
only in non-authorized libraries.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to