Hi, Regarding the access list for UCATS, if they are for SMS datasets, you do not need to have them with UPDATE(*); READ(*) will be enough. Only those creating non-SMS entries will need UPDATE access.
Best Regards "Do the difficult things while they are easy and do the great things while they are small. A journey of a thousand miles must begin with a single step." Laozi From: Allan Staller <allan.stal...@hcl.com> To: IBM-MAIN@LISTSERV.UA.EDU Date: 2019-09-25 15:34 Subject: [EXTERNAL] Re: Tracing RACF? Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> That is not considered a good practice in RACF circles. The best practice would be: MCAT - UACC(NONE) READ(*) ALTER(sysprogs) (note: No update access except via sysprogs) UCAT - UACC(NONE) UPDATE(*) ALTER(sysprogs) -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Tom Conley Sent: Wednesday, September 25, 2019 9:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Tracing RACF? On 9/25/2019 9:57 AM, Joao Bentes wrote: > Hi, > > If memory serves me right, as long as you have ALTER to the dataset, > you need update to the catalog in order to create it, but you do not > need any access to the catalog in order to delete it. > > Best Regards > > > "Do the difficult things while they are easy and do the great things > while they are small. A journey of a thousand miles must begin with a > single step." > Laozi > > > > From: Sean Gleann <sean.gle...@gmail.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 2019-09-25 12:06 > Subject: [EXTERNAL] Tracing RACF? > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > > > Following a set of somewhat distressing events here, I discovered - > the hard way - that our master catalog was poorly protected, and so I > now have to fix it. The situation is that all users of the my system > can create, read, write, update, delete files that are cataloged in the MasterCat. > > The original intention was that each user-id is defined in the MCat as > an alias that points to one of several User Catalogs, depending on the > user's 'department' within the company. That way, user id 'X1' creates > 'X1.TEST', and it gets cataloged in a UCAT. > > So far, so good. > > Now I've found that if 'X1' creates file 'TEST1', it gets cataloged in > the MCAT. In order to prevent this, I've used existing information to > act as a model for permit 'MASTERV.CATALOG' generic id(X1) > access(read) and specified that. > > Now, if user X1 tries to create 'X1.TEST', the result is a RACF > authorisation failure. > > Again, so far, so good > > Taking the test a bit further though, I've now found that user X1 is > allowed to delete file 'TEST1' from the MCat! > > My conclusion so far is that X1 must be getting the required access > rights from another user id/group/etc, but I can't see anything > apposite in any examination I do of the RACF rules (I use output from > the DBSYNC Rexx procedure for this). > > > So... Can anyone spot my error and suggest a different 'permit' > command, please? > Alternatively, I looked at the idea of tracing RACF activity on behalf > of a specific user with SET TRACE(USERID(X1)) - but I can't see where > generated output goes to nor how to interrogate it. I *have* seen > mention of using GTF for this purpose, along with IPCS, but my > experience with both those tools is so limited that I didn't look much > further in those references - skipped on past them, looking for other > possibilities but not finding any. > > Any help gratefully appreciated > Sean > If you're the owner of the dataset, you will get the authority to delete the catalog entry. You should have your master cat set up with UACC(READ) and all your usercats with UACC(UPDATE). Put them in the global access table for a nice performance boost. Only allow update and alter to the master cat and alter for usercats to your catalog administrators. Good luck. Regards, Tom Conley ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Salvo disposto de outra forma acima: / Unless stated otherwise above: Companhia IBM Portuguesa, S.A. Sociedade Anónima com o Capital Social de ? 15.000.000 Registada na Conservatória do Registo Comercial de Lisboa, sob o número único fiscal e de matrícula 500068801 Edifício ?Office Oriente? Rua do Mar da China, Nº 3 Parque das Nações, 1990-138 LISBOA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
