On 7/24/2013 8:09 AM, Lizette Koehler wrote:
I might slightly disagree with removing the SAF and APF requirements.
>From a sysprog perspective, I can allow my applications groups access to LIST
functions but NOT REC/APP/ACC. This is beneficial. I do not mind if they want to
look, I just do not want them to touch. In fact I would encourage them or anyone
to be able to research fixes.
I do not want them to be able to rec/app/acc fixes on my zones.
This is accomplished in SMP/E (and all other system utilities) by
granting the appropriate access to the data sets being manipulated. In
this case, READ access to the CSI as well as target/DLIB data sets would
seem appropriate.
If a shop wants to make it open, then just make UACC on the facilities open.
But, the integrity exposure--which I have purposely tried to refrain
from mentioning directly--still remains! SMP/E's FACILITY class
resources do not eliminate the exposure, rather they limit it to jobs
that can be run by "trusted" individuals. Some might call this a
"kludge". At best, it's a Band-Aid fix.
And as for APF. It is another protection in the system. Since an APF
authorized library can control to some extent the ability to modify some
storage areas, I think this is also fine. Some of the functions in SMP/E could
be dangerous if allowed to run amuck.
You have this exactly backwards. APF authorization of SMP/E is the
reason the exposure exists in the first place. Removal of that attribute
completely solves the problem.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
