To recap: PROTECTALL is off. No RACF profile protects the DSN in question. The MCAT is protected by a profile. An admin creates the non-SMS dataset TEST which gets catalogued in the MCAT. A non-admin deletes the dataset which results in an orphan catalog entry. You are surprised.
Why? The data set is completely unprotected. The fact that it is on a non-SMS volume or catalogued in the MCAT makes very little difference. Under these conditions, ANY USER IS AUTHORIZED to edit the contents or delete the dataset. There are probably other actions available. The user may even be able to rename the data set to XTEST which would result in it being no longer catalogued in addition to the orphan entry. The user may be able to rename the data set to DSN that gets catalogued in a UCAT which would result in two catalog entries (a correct UCAT and an orphan MCAT). If the admin had specified a STORCLAS when creating the dataset, it would have been placed on an SMS volume. I don't think anything would have changed (except possibly for the rename). If the admin had used a DSN that meets your ACS qualifications but is still not protected by a profile, the previous paragraph would still apply If the admin had used a DSN that is catalogued in a UCAT but is still not protected by a profile, the data set is still completely unprotected but now you will not be left with an orphan catalog entry. If the admin had specified KEEP instead of CATLG, the dataset would still be unprotected but there would not be an MCAT entry to be orphaned. The catalog structure has nothing to do with data set protection. The fact that SMS data sets must be catalogued would prevent your non-admin from creating TEST in the first place but once it is created the barn door is wide open. The fact that PROTECTALL is off and you have many unprotected data sets is a major security hole. Any unprotected data set is just a problem waiting to bite you. > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Sean Gleann > Sent: Thursday, October 03, 2019 5:17 AM > To: [email protected] > Subject: Re: Tracing RACF? > > You mean, did I actually specify a volser on the "Data Set List Utility" > panel? > In all cases up to now, the answer is 'No'. > But your query prompted a couple of experiments, all to no avail I'm afraid. > If I do specify the volser as well as the dsn, the only difference is that > the 'delete confirmation' panel that opens up has an extra option in it. > Instead of just "Set data set delete confirmation off", I also get > "Uncatalog data set upon deletion" - which is already selected with a '/'. > If I allow the deletion to go ahead with that selection, the only > difference is that I don't get to see a RACF violation on the MCAT. The > file still gets removed from the volume, leaving the orphaned MCAT entry > behind, just as before - but now I don't know about the uncatalog failure. > Regards > Sean ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
