On 2 Jul 2007 09:04:20 -0700, in bit.listserv.ibm-main you wrote: >> >> Of course this facility should be highly restricted since this >> probably bypasses all dataset access checking. This comment would >> apply to the other programs mentioned as well. >True, our manual says: > >DSF ABSOLUTE TRACK OPERATIONS > >When the FROM/TO operands are used in FDRDSF or FDRCOPY to access tracks >by their absolute address, FDR will check for authority to the volume >with: > > RACROUTE REQUEST=AUTH,APPL='FDR',CLASS='DASDVOL',ENTITY=volser, > ATTR=access > >where "access" is READ for DUMP and PRINT and for the input volume on COPY >and is ALTER for RESTORE and for the output volume on COPY. If a DASDVOL >profile exists for the volume being accessed, and the user does not have >the requested access authority, the operation will be terminated. FDR does >not attempt to determine what datasets the requested tracks belong to, or >to perform checking at the dataset level. > >If the installation decides that this approach does not provide adequate >security, then absolute track operations can be disabled completely, as >discussed under NOABSTRK, in Section 90.12 SECURITY OPTIONS (PANEL >A.I.4.1). > >Note that if no DASDVOL profile exists the PRINT is permitted, another >part of the manual strongly recommends DASDVOL profiles. > >The STGADMIN authority is another way to do it; it permits PRINT >operations if the user has the STGADMIN authority. > This type of restriction would be adequate as would restricting the area to a data set opened by the utility where the security system of choice or affliction is invoked. I would assume that DASDVOL access would be tightly controlled and monitored. Security is a zoo.
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
