[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: GDG base/Catalog authority
From:       J O Skip Robinson <Jo.Skip.Robinson () SCE ! COM>
Date:       2015-07-31 22:55:53
Message-ID: SN1PR0101MB15200D826E5443560B5EDB91CE8A0 () SN1PR0101MB1520 ! prod ! exchangelabs ! com
[Download RAW message or body]

I've come across a few folks in our profession who use 'quack' in a similar way. \
Never appealed to me enough to join the fun.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
JO.Skip.Robinson@sce.com

-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of Richard \
                Pinion
Sent: Friday, July 31, 2015 2:43 PM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: GDG base/Catalog authority

And who can forget Majors Duck and Dodge of the Three Stooges.  As a side, side note, \
I seem to remember an access method called "duck" or "dodge".  It was an accessed \
method developed for a banking application that ran on IBM mainframes, circa 1970's - \
1980's???  Did I dream that, or can someone verify that story?



--- vicjimar@HOTMAIL.COM wrote:

From: Victor Jiménez <vicjimar@HOTMAIL.COM>
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: GDG base/Catalog authority
Date:         Fri, 31 Jul 2015 16:23:14 -0500

Hahahahaha... you really made me laugh, guys.

I used 'duck' just because here in Mexico people sometimes use the word 'pato' (duck) \
as an adjective for a dummy or an unrecognized brand thing.  So if you create a dummy \
user, you can refer to it as 'usuario pato' ('duck user'), or if you buy something \
that looks like if it is of a recognized brand, but it's not, then you say it is \
'marca patito' ('little duck' brand).

Have a nice weekend,

     V.

> Date: Fri, 31 Jul 2015 15:40:08 +0000
> From: Alan.Buschmann@FISGLOBAL.COM
> Subject: Re: GDG base/Catalog authority
> To: RACF-L@LISTSERV.UGA.EDU
> 
> Just a little muse is called for here..."Why a duck?"  Couldn't help myself.
> 
> Regards.
> 
> Alan Buschmann
> IT Security Analyst Spclst
> CISO Security Authorization Svcs
> 
> FIS
> 4900 W Brown Deer Road | Milwaukee, WI | 53223-2422
> Office: 414 357-3755
> Alan.Buschmann@FISglobal.com
> 
> 
> -----Original Message-----
> From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf 
> Of Victor Jiménez
> Sent: Wednesday, July 22, 2015 1:55 PM
> To: RACF-L@LISTSERV.UGA.EDU
> Subject: Re: GDG base/Catalog authority
> 
> Robert,
> 
> The user doesn't have the OPERATIONS attribute.  The IDCAMS command was this:
> 
> DEFINE GDG(NAME('DUCK.JCL.TEST')   -
> LIMIT(2)                -
> NOEMPTY                 -
> SCRATCH)
> 
> Obviously, there's neither a user nor a group called 'DUCK'.  Now, I've been doing \
> some tests and here's what I found: 
> * If the user trying to create the GDG base has READ access to the master catalog, \
> he gets this message: 
> ICH408I USER(TESTUSR ) GROUP(ALTPR1  ) NAME(TEST USER    )
> CATALOG.SYSXX.ZOSV1D.MASTER CL(DATASET ) VOL(XX1DMS)
> INSUFFICIENT ACCESS AUTHORITY
> FROM CATALOG.** (G)
> ACCESS INTENT(UPDATE )  ACCESS ALLOWED(READ   )
> 
> * If the user trying to create the GDG base has UPDATE access to the master \
> catalog, the GDG base is created, and it looks like this: 
> Command - Enter "/" to select action                  Message           Volume
> -------------------------------------------------------------------------------
> DUCK.JCL.TEST                                                               ??????
> 
> * But when he tries to DELETE it, he gets this message:
> 
> ICH408I USER(TESTUSR ) GROUP(ALTPR1  ) NAME(TEST USER     )
> DUCK.JCL.TEST CL(DATASET ) VOL(XX1DMS)
> RESOURCE NOT PROTECTED
> ACCESS INTENT(ALTER  )  ACCESS ALLOWED(NONE   )
> IDC3018I SECURITY VERIFICATION FAILED+ IDC0551I ** ENTRY DUCK.JCL.TEST 
> NOT DELETED IDC0014I LASTCC=8 IDC3009I ** VSAM CATALOG RETURN CODE IS 
> 56 - REASON CODE IS IGG0CLFT-6
> 
> What gave away that the problem was with the master catalog was the VOL field, \
> because it is the one in which it is allocated. 
> * Finally, I granted ALTER access to the user, and he was now able to delete the \
> wrong GDG base.  Here's the message he got: 
> IDC0550I ENTRY (B) DUCK.JCL.TEST DELETED
> ***
> 
> So, at least empirically I've learned that if you want to create an 
> entry on the master catalog you need UPDATE access, but if you want to 
> delete it, you need ALTER... =)
> 
> Thanks to all for your answers,
> 
> V.
> 
> -----------
> 
> > Date: Wed, 22 Jul 2015 06:12:20 -0400
> > From: R.Hansel@RSHCONSULTING.COM<mailto:R.Hansel@RSHCONSULTING.COM>
> > Subject: Re: GDG base/Catalog authority
> > To: RACF-L@LISTSERV.UGA.EDU<mailto:RACF-L@LISTSERV.UGA.EDU>
> > 
> > Victor,
> > 
> > Does the user have OPERATIONS authority?
> > 
> > Is SETROPTS AUDIT(DATASET) active? If so, there may be an SMF 80 record DEFINE \
> > event associated with the creation of the GDG base that you could examine to see \
> > what authority might have been used. 
> > Was the user using IDCAMS to create the GDG base? If yes, can you show us the \
> > IDCAMS command he used? 
> > Regards, Bob
> > 
> > Robert S. Hansel
> > Lead RACF Specialist
> > RSH Consulting, Inc.
> > 617-969-8211
> > www.linkedin.com/in/roberthansel<http://www.linkedin.com/in/robertha
> > nsel> 
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_RSH-
> > 5F 
> > RACF&d=AwIFAw&c=3BfiSO86x5iKjpl2b39jud9R1NrKYqPq2js90dwBswk&r=KJFS4M
> > uC 
> > anPS7XPqfzev_ZaCcvhhQvZssHbhC2zcT_c&m=dAmknd8Lg4AMdvr7cIGKv2MYzOkM4e
> > GE NXoruQYPgus&s=USy6pZSCd5azweaF0-VmnPgn2WqqvPup6MhbKtQjpqs&e=
> > www.rshconsulting.com<http://www.rshconsulting.com>
> > --------------------------------------------------------------------
> > --
> > -
> > 2015 RACF Training
> > - Securing z/OS UNIX  - WebEx - SEPT 22-25, 2015
> > - Audit & Compliance Roadmap - Boston - NOV 10-13, 2015
> > - Intro & Basic Admin - WebEx - DEC 7-11, 2015
> > --------------------------------------------------------------------
> > --
> > -
> > 
> > -----Original Message-----
> > Date:    Tue, 21 Jul 2015 11:56:15 -0500
> > From:    Victor Jiménez <vicjimar@HOTMAIL.COM<mailto:vicjimar@HOTMAIL.COM>>
> > Subject: Re: GDG base/Catalog authority
> > 
> > Hi David,
> > 
> > Well, I'm pretty sure the user didn't specify a catalog, that's why 
> > it ended up in the master.  So, again, I have some cleaning to do in 
> > the master catalog's ACL... =S
> > 
> > Thanks,
> > 
> > V.
> > 
> > 
> > > Date: Tue, 21 Jul 2015 11:27:13 -0500
> > > From: DEvans@TRUSTMARK.COM<mailto:DEvans@TRUSTMARK.COM>
> > > Subject: Re: GDG base/Catalog authority
> > > To: RACF-L@LISTSERV.UGA.EDU<mailto:RACF-L@LISTSERV.UGA.EDU>
> > > 
> > > It is an Alias defined in the master catalog that would send the 
> > > catalog entry to a user catalog.  If the Alias was not defined, 
> > > the catalog entry would have gone into the Master Catalog.
> > > 
> > > David Evans, CISSP
> > > Systems Programmer
> > > Technical Services
> > > Trustmark National Bank
> > > Office: (601) 208-7930
> > > 
> > > 
> > > 
> > > From:   Victor Jiménez <vicjimar@HOTMAIL.COM<mailto:vicjimar@HOTMAIL.COM>>
> > > To:     RACF-L@LISTSERV.UGA.EDU<mailto:RACF-L@LISTSERV.UGA.EDU>
> > > Date:   07/21/2015 11:22 AM
> > > Subject:        Re: GDG base/Catalog authority
> > > Sent by:        RACF Discussion List \
> > > <RACF-L@LISTSERV.UGA.EDU<mailto:RACF-L@LISTSERV.UGA.EDU>> 
> > > 
> > > 
> > > Hayim/Lennie,
> > > 
> > > Well, it's getting stranger...  We have PROTECTALL on.  The actual 
> > > data sets were not created, only the GDG base.  There are no exits 
> > > that could be interfering.  I checked and the user had UPDATE to 
> > > the master catalog when he created the GDG base...
> > > 
> > > Fortunately we're going to migrate to z/OS 2.1, an thus I have a 
> > > nice little lab LPAR to play with and I'll try to recreate the whole event.
> > > 
> > > Thanks for your replies.  And I thabk you, Hayim, for pointing out 
> > > that I have to do some cleaning to the ACL of our master catalog!!
> > > 
> > > V.
> > > 
> > > > Date: Tue, 21 Jul 2015 15:24:23 +0000
> > > > From: hsokolsky@DTCC.COM<mailto:hsokolsky@DTCC.COM>
> > > > Subject: Re: GDG base/Catalog authority
> > > > To: RACF-L@LISTSERV.UGA.EDU<mailto:RACF-L@LISTSERV.UGA.EDU>
> > > > 
> > > > It's a bit of a mixed situation - you are not showing the whole picture.
> > > > 
> > > > So....
> > > > 
> > > > 1. The UACC for a user catalog should be UPDATE.
> > > > 2. The UACC for a master catalog should be READ.
> > > > 
> > > > That combination alone should have been enough to prevent the 
> > > > GDG create
> > > for a HLQ that does not have a catalog alias.
> > > > 
> > > > I am puzzled as well. The DEFINE GDG should require ALTER to the 
> > > > DSN, as
> > > well as UPDATE to the catalog. UPDATE to the catalog itself should 
> > > not be enough. To see what authority is used to define the GDG 
> > > base, you should recreate the situation with UAUDIT on the UserID performing \
> > > the action ... and then look at the SMF data.
> > > > 
> > > > 
> > > > Hayim Sokolsky
> > > > Manager, Mainframe Security Architecture Technology Risk 
> > > > Management DTCC Tampa
> > > > Direct: +1 813 470-2177 | 
> > > > hsokolsky@dtcc.com<mailto:hsokolsky@dtcc.com>
> > > > 
> > > > 
> > > > 
> > > > Visit us at www.dtcc.com<http://www.dtcc.com> or follow us on 
> > > > Twitter @The_DTCC  and on
> > > LinkedIn.
> > > > To learn about career opportunities at DTCC, please visit
> > > dtcc.com/careers.
> > > > 
> > > > Classification:  DTCC Non-Confidential (WHITE)
> > > > 
> > > > The views I have expressed in this email are my own personal 
> > > > views, and
> > > are not endorsed or supported by, and do not necessarily express 
> > > or reflect, the views, positions or strategies of my employer.
> > > > 
> > > > -----Original Message-----
> > > > From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On 
> > > > Behalf Of
> > > Victor Jiménez
> > > > Sent: Tuesday, July 21, 2015 10:56
> > > > To: RACF-L@LISTSERV.UGA.EDU<mailto:RACF-L@LISTSERV.UGA.EDU>
> > > > Subject: GDG base/Catalog authority
> > > > 
> > > > Hi,
> > > > 
> > > > Last week a user defined a GDG base with an invalid HLQ (i.e. it 
> > > > did not
> > > match a group or user id already defined in RACF), but when he 
> > > tried to delete it, he got a message like this:
> > > > 
> > > > ICH408I USER(USER01) GROUP(USERSGRP) NAME(JOHN JONES)
> > > > MEXP.GDGD.JCL.EXIT CL(DATASET ) VOL(MP1DK1)
> > > > RESOURCE NOT PROTECTED
> > > > ACCESS INTENT(ALTER  )  ACCESS ALLOWED(NONE   )
> > > > IDC3018I SECURITY VERIFICATION FAILED+ IDC0551I ** ENTRY 
> > > > MEXP.GDGD.JCL.EXIT NOT DELETED IDC0014I LASTCC=8 IDC3009I ** 
> > > > VSAM CATALOG RETURN CODE IS 56 - REASON CODE IS IGG0CLFT-6
> > > > 
> > > > I realized that all of this was caused because a GDG base is not 
> > > > really
> > > a data set, but rather a catalog entry, and it didn't took long to 
> > > notice that all that the user needed to be able to delete the GDG 
> > > base was ALTER access to the catalog to which the GDG base was 
> > > related.  I granted such access to the user and he could finally 
> > > delete the GDG base.  The day after I examined the user's records 
> > > on zSecure Access Monitor and found out that when he created the 
> > > GDG base he had and UPDATE access to the catalog mentiones above.  
> > > In conclusion, in order to create a GDG base you need UPDATE 
> > > access to the catalog, and to delete it you need ALTER.  The question is: Is \
> > > this conclusion right?  Am I missing something?
> > > > 
> > > > Thanks in advance,
> > > > 
> > > > V.


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic