And what command is the non-admin user issuing to perform the delete? > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of retired mainframer > Sent: Tuesday, October 01, 2019 5:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Tracing RACF? > > What is the status of the SETROPTS PROTECTALL option? > > Is there any data set profile that covers the dataset? > > Is there a global access checking table entry that covers the dataset? > > Does the non-admin user have the OPERATIONS attribute? > > Is there a DASDVOL profile that covers the non-SMS volume in question? > > > -----Original Message----- > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > > Behalf Of Sean Gleann > > Sent: Tuesday, October 01, 2019 3:10 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Tracing RACF? > > > > Joao: yes, I have tried that, but it really doesn't give the information > > that I want - I can see the monitored user creating and deleting file, but > > I don't see anything about the RACF profiles that were used. > > > > Having said that, I have managed to move things along. > > The situation I now have is that an 'ordinary' user of my system(s) - as > > opposed to an 'administrator' user (there are three of us at this site) - > > cannot update the MCAT, so creating files that do not have the user's id as > > the first qualifier is now impossible. > > 'Administrators', on the other hand, can create and delete files at will. > > All of which is OK as far as I'm concerned. > > > > But (there's always a 'but'...) > > If an admin user creates a file named 'TEST' (for instance), the file is > > not covered by my SMS rules, and so it gets placed on one of the 5 > > non-SMS-controlled disks that my PARMLIB(VATLSTxx) member identifies as > > being mounted 'PRIVATE'. I'd rather that didn't happen, but we're talking > > about an 'admin'-type user here, and they're supposed to know what they're > > doing, so things are OK up to this point. > > But now it appears that a non-admin user can delete the file, but not > > uncatalog it. The file disappears from the selected disk's VTOC, but the > > MCAT entry remains since the user is not allowed to update the MCAT. If > > this is allowed to continue I'll end up with an MCAT full of orphan entries. > > > > As I say, I've managed to move things along a bit, so my original query > > about 'Tracing RACF' is no longer an issue. > > Right now, I'm trying to improve my system's security so that users can > > create/delete their own files, but cannot do that to anyone else's, nor to > > files that are not covered by SMS. > > ---------------------------------------------------------------------- > 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
