When the 3.4 list was requested, was a volser specified on the panel? > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Sean Gleann > Sent: Wednesday, October 02, 2019 12:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Tracing RACF? > > Answering 'retired mainframer's questions (and I'll probably be joining you > within the next year) > > *What is the status of the SETROPTS PROTECTALL option?* > A 'SETROPTS LIST' shows: 'PROTECT-ALL OPTION IS NOT IN EFFECT'. I > tried switching that with 'setropts protectall(warning)', but the sheer > volume of output that is generated swamps everything else. > *Is there any data set profile that covers the dataset?* > No - filenames 'TEST' and 'TEST1' (the ones I have been using for > this) are not specifically identified anywhere in RACF > *Is there a global access checking table entry that covers the dataset?* > Not sure exactly what this means, so I don't know how to check. But > see previous answer > *Does the non-admin user have the OPERATIONS attribute?* > No. > *Is there a DASDVOL profile that covers the non-SMS volume in question?* > Yes - the DBSYNC output shows 'redefine dasdvol v* uacc(none)', > followed by 'permit v* class(dasdvol) reset' (and 'v*' covers the volids > involved). After that, there are no specific permissions defined > *And what command is the non-admin user issuing to perform the delete?* > Just a simple 'D' against the file in an ISPF 3.4 list. > > Regards > Sean > > > > > On Tue, 1 Oct 2019 at 16:32, retired mainframer <retired-mainfra...@q.com> > wrote: > > > 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 > > > > ---------------------------------------------------------------------- > 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
