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
