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
