W dniu 2019-09-25 o 15:57, Joao Bentes pisze:
Hi,
If memory serves me right, as long as you have ALTER to the dataset, you
need update to the catalog in order to create it, but you do not need any
access to the catalog in order to delete it.
Best Regards
"Do the difficult things while they are easy and do the great things while
they are small. A journey of a thousand miles must begin with a single
step."
Laozi
From: Sean Gleann <[email protected]>
To: [email protected]
Date: 2019-09-25 12:06
Subject: [EXTERNAL] Tracing RACF?
Sent by: IBM Mainframe Discussion List <[email protected]>
Following a set of somewhat distressing events here, I discovered - the
hard way - that our master catalog was poorly protected, and so I now have
to fix it. The situation is that all users of the my system can create,
read, write, update, delete files that are cataloged in the MasterCat.
The original intention was that each user-id is defined in the MCat as an
alias that points to one of several User Catalogs, depending on the user's
'department' within the company. That way, user id 'X1' creates 'X1.TEST',
and it gets cataloged in a UCAT.
So far, so good.
Now I've found that if 'X1' creates file 'TEST1', it gets cataloged in the
MCAT. In order to prevent this, I've used existing information to act as a
model for
permit 'MASTERV.CATALOG' generic id(X1) access(read)
and specified that.
Now, if user X1 tries to create 'X1.TEST', the result is a RACF
authorisation failure.
Again, so far, so good
Taking the test a bit further though, I've now found that user X1 is
allowed to delete file 'TEST1' from the MCat!
My conclusion so far is that X1 must be getting the required access rights
from another user id/group/etc, but I can't see anything apposite in any
examination I do of the RACF rules (I use output from the DBSYNC Rexx
procedure for this).
So... Can anyone spot my error and suggest a different 'permit' command,
please?
Alternatively, I looked at the idea of tracing RACF activity on behalf of
a
specific user with
SET TRACE(USERID(X1)) - but I can't see where generated output goes to nor
how to interrogate it. I *have* seen mention of using GTF for this
purpose,
along with IPCS, but my experience with both those tools is so limited
that
I didn't look much further in those references - skipped on past them,
looking for other possibilities but not finding any.
Any help gratefully appreciated
Sean
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
MCAT always require UPDATE when you want to create and catalog new
dataset in this BCS (catalog).
Of course it is good idea to restrict the update to limited group of
power users (admins).
UCAT - for non-SMS-managed datasets also require UPDATE. However for
SMS-managed datasets even NONE is sufficient. It is good idea to give
the UPDATE to unwashed masses, especially because UPDATE does not mean
everyone can open UCAT as regular VSAM and modify it. No, the only
things allowed by UPDATE are legal things like catalog and uncatalog
datasets (under RACF control).
Regarding ALTER - IMHO it should be assigned to NOBODY. Nobody except
special userid used only for catalog maintenance. Even catalog
administrator should not have ALTER for his daily TSO user, because it's
dangerous.
My €0,02
--
Radoslaw Skorupka
Lodz, Poland
======================================================================
Jeśli nie jesteś adresatem tej wiadomości:
- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza)
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać
karze.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: [email protected]. Sąd Rejonowy dla m. st.
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237,
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
01.01.2019 r. wynosi 169.347.928 złotych.
If you are not the addressee of this message:
- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have
printed out or saved).
This message may contain legally protected information, which may be used
exclusively by the addressee.Please be reminded that anyone who disseminates
(copies, distributes) this message or takes any similar action, violates the
law and may be penalised.
mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: [email protected]. District Court for the Capital
City of Warsaw, 12th Commercial Division of the National Court Register, KRS
0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN
169.347.928 as at 1 January 2019.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
