I started this thread back in September, and got a lot of useful advice from responders for which a heartfelt 'Thank You'.
Now I'm at the point of putting that advice in to action and I'm afraid I've hit an apparent problem (in my eyes, at least). I'm also using a RedBook "ABCs of z/OS System Programming Volume 6" (SG24-6986), page 51ff as a source of guidance. Per that book, the first thing I need to do to protect a specific file is to use an 'ADDSD' command to define the file name. If I try to ADDSD 'ABC.DEF' UACC(NONE), I get "ICH09006I USER OR GROUP ABC NOT DEFINED TO RACF" Well - that's right. High-level qualifier 'ABC' is not a user-id, nor is it group name and it is not intended to be, either. 'ABC' is used to identify files that are used by multiple groups of users - there is no single 'owner' as such. By implication, I've got to create a user (or group) named ABC in order to proceed. Extending that implication, I've got to create users (or groups) for every single HLQ currently in use on my system(s). That can't be right, surely. I've got to be missing something somewhere. Can anyone shine a light on this, please? Regards Sean On Mon, 7 Oct 2019 at 13:53, Sean Gleann <sean.gle...@gmail.com> wrote: > "...The fact that SMS data sets must be catalogued..." was the missing bit > for me. > I've never before worked in a position where I was allowed to use non-SMS > datasets, so the possibilities involved with such things was something I'd > never even begun to consider. > > When this particular situation was 'discovered', my main worry was that > all my SYS1... type datasets were equally at risk. I've since shown that > not to be the case, but it's not due to RACF or SMS rules. All those > datasets are on disks that are attached from VM in R/O mode. To alter > anything in them requires the 'owning' VM to be started up, and - at this > site - *that* requires management sanction. > > Thank you for all your help in this. As you've highlighted, I'm going to > have to switch PROTECTALL on and then handle all the screams of dismay from > developers. > > > Regards > > Sean > > On Thu, 3 Oct 2019 at 15:30, retired mainframer <retired-mainfra...@q.com> > wrote: > >> 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 <IBM-MAIN@LISTSERV.UA.EDU> On >> > Behalf Of Sean Gleann >> > Sent: Thursday, October 03, 2019 5:17 AM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
