On Fri, 28 Jul 2017 23:18:27 +0300, ITschak Mugzach <[email protected]> wrote:
A racf third party check >will be performed with the dsname & actual volser. >this function is intended to serve security administrators and product >developers that are not familiar with RACF and required to define the >security requirements of their applications. different users can be >specified as a parameter to the checker. In the fully general case (that is, to handle everything that could occur) you also need to consider: (a) Conditional access: Your 3rd-party check can fail when you do the check, but succeed when the real program does the check, because access is granted only to program X from library Y. (b) Different users can have different security characteristics at different times. For example, a user's connection to the group that grants access to a data set might be set to expire tomorrow. The check you run today will succeed, but the job will fail when run. (c) You say you're going to do a RACROUTE REQUEST=AUTH specifying the dsname, volser, and user. In addition: (c1) For data sets being created, you need to do a RACROUTE REQUEST=VERIFY with ENVIR=VERIFY, not a REQUEST=AUTH. You will also need to know the storage group (I think) that the data set will be allocated to, and you may need to know information from the DFP segment of the covering profile or the user. You will also (again, for the general case) need to know whether a discrete profile will be created, and there are several aspects that control that. I won't get into further details now (as I would have to remember them, and do some research). (c2) You'll need to know if the data set is VSAM or non-VSAM. For non-VSAM you need to pass the volume serial of the data set itself. For VSAM, you need to pass the volume serial of the catalog where it's cataloged, and you need to find and pass the cluster name, not the name in the JCL. For either VSAM or non-VSAM you also need to pass the RACF indicator (from the DSCB (non-VSAM) or the cluster's sphere record (VSAM), to handle the general case where discrete profiles may be in use. (d) For the general case you need to handle security levels and/or security labels. Simply passing a user ID will not handle this if security labels are in use. (e) The calls are different for data sets on TAPE, and how they are different depends on the settings in PARMLIB(DEVSUPxx) and/or the tape management system that may be in use. I'm sure I've forgotten several other points I intended to make. The net, though, is that if you're writing this for a specific site then there may be some things that you can assume are true today (e.g., maybe they don't use conditional access, or maybe they don't use discrete profiles, or seclabels). But if you're writing a product you probably shouldn't make those assumptions. Also, even for a local program, the assumptions can easily become wrong, and then you'll be giving incorrect answers. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
