We have TSS and it can tell exactly where a user gets/inherits a certain authorization from. Can't RACF do the same?
Kees. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Sean Gleann > Sent: 25 September, 2019 13:06 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Tracing RACF? > > 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 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
