On 2/7/19 5:57 AM, Elardus Engelbrecht wrote: > Steff Gladstone wrote: > > Please consider subscribing to RACF-L at > http://listserv.uga.edu/archives/racf-l.html > > >> We have an TSO application for end-users that allows them to update certain >> VSAM and PDS files. In order for them to update these files we of course >> have to give their users update-authorization under RACF for those files. > Correct, I am assuming you're refering to VSAM and PDS datasets. > > >> We want to limit their ability to update the files only via the particular >> TSO application (or via a particular I/O routine used by the application) >> and not via any other application program or IBM utility (e.g., IEBCOPY, >> ISPF on-line edit or utilities, etc.). > I don't think it is possible, but if the application is a program (load > module) which is CALLed in TSO, then it should be possible. See below. > > I don't think you can protect I/O routines unless you front-end a SVC routine > with a ROY exit which is not recommended. > > For REXX programs, I don't think it is possible to protect it via RACF, > unless of course the dataset where it is residing is protected properly.
It is possible with REXX programs, provided you have a product (like REXXTools/MVS) that allows you to convert REXX into secure program load modules. Note that program-controlled access to datasets can be tricky to maintain: that all programs in all datasets from which the address space could possibly load a module should be covered by a PROGRAM profile, even if UACC allows everyone to access the load modules, or the program-controlled access environment will be lost and program-controlled dataset access will not be honored. It helps for problem resolution if apps that depend on program-controlled access to datasets can check for loss of program-controlled environment and give an explicit error message if that is the problem, rather than just terminating on a RACF insufficient access open failure. Access failure from a previously working app is invariably the side effect of someone changing some totally unrelated data sets and omitting required updates to relevant PROGRAM profiles. Joel Ewing > >> How can we define the RACF authorizations in such a way as to limit the >> end-users' update capabilities to the application (or to a particular I/O >> routine) alone? > From Knowledge Centre > > (at > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.icha400/permit.htm#permit) > > > ... you can do that PErmit for Datasets for conditional access via programs > (load modules): > > PERMIT 'XXX.YYY' ID(SMITH) ACCESS(READ) WHEN(PROGRAM(ABC)) > > or if you want to limit it for a specific LPAR, this: > > PERMIT 'XXX.YYY' ID(SMITH) ACCESS(READ) WHEN(SYSID(ABC)) > > > Alternative: You can limit a program to be used on a specific LPAR, like this > COBOL example: > > permit IGY* class(PROGRAM) id(?) access(READ) when(SYSID(????)) > > >> Would the same (or similar) definitions work for a site using Top Secret >> instead of RACF? > I believe they can also do that, however, I don't know wha the command(s) are > for that. > > HTH! > > Groete / Greetings > Elardus Engelbrecht -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
