Sean, Deleting datasets from non-SMS managed volumes without dataset access authority (assuming the datasets are protected by DATASET profiles to which the users do not have ALTER access) may be DASDVOL authorization. See if your users have ALTER access to DASDVOL profiles corresponding to your DASD volsers. DASDVOL also honors OPERATIONS authority, so ensure the non-admin users don't have this authority.
See article "RACF SMF Tidbits" in the July 2016 edition of our RACF Tip newsletter. https://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__July_2016.pdf Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.twitter.com/RSH_RACF www.rshconsulting.com -----Original Message----- Date: Tue, 1 Oct 2019 11:10:21 +0100 From: Sean Gleann <sean.gle...@gmail.com> 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. Regards Sean On Tue, 1 Oct 2019 at 04:24, Jon Perryman <jperr...@pacbell.net> wrote: > On Wednesday, September 25, 2019, 07:34:05 AM PDT, Allan Staller < > allan.stal...@hcl.com> wrote: > > > That is not considered a good practice in RACF circles. The best > practice would be: > > > MCAT - UACC(NONE) READ(*) ALTER(sysprogs) (note: No update access > except via sysprogs) > > Any system where the master catalog is not tightly controlled is at great > risk and could become unusable. Any user can delete any alias in this > environment. Potentially DB2, CICS, IMS or any number of important aliases > could be lost. > > It's been many years since I've done anything with security. I believe at > that time, IDCAMS DELETE NOSCRATCH for non-sms datasets was not controlled > because it was only catalog services and no actual I/O was occurring. Has > this problem been fixed? If not, then anyone can uncatalog sys1.linklib or > sys1.lpalib thus causing the IPL to fail. > > Why aren't aliases created at the same time as the User? Additionally, > data is out of control on your system. The RACF admin has not reviewed the > security implication for aliases. > > Jon. > > ---------------------------------------------------------------------- > 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
