Rex,
Here is the relevant cut/paste from the manuals, and as Steve mentioned, DEF
AIX doesn’t require access to base, just authority to create the AIX, but
BLDINDEX does require update to the base.
In your case:
Table 2. Required Security Authorization for VSAM Data Sets
-----------------------------------------------------------------------
|Function Performed | Required RACF | Required RACF | Comments |
| | for Data Set | for Catalog | |
-----------------------------------------------------------------------
|Define alternate | Alter | Update |See notes 2 and 3|
|index | | | |
-----------------------------------------------------------------------
Notes:
2. Authorization is always to the cluster name for VSAM components
cataloged with the integrated catalog facility. Integrated
catalog facility does not check for individual component names
such as data, index, path, or alternate index.
3. No authority is required to the catalog for the define of
SMS-managed data sets unless the catalog is the master catalog.
Update authority is required if the catalog is a master catalog.
and:
Table 5. Required Security Authorization for Data Set Operations
-----------------------------------------------------------------------
|Function Performed | Required RACF | Required RACF | Comments |
| | for Data Set | for Catalog | |
-----------------------------------------------------------------------
|BLDINDEX | n/a | Update |Authority is to |
| | | |the base cluster.|
-----------------------------------------------------------------------
Basically, authorization checking is done against the AIX being defined (ALTER
access to the AIX cluster name as shown in the table above) not the VSAM
dataset the AIX relates to. Checking against the related VSAM
cluster will be done when accessed by BLDINDEX.
So, this is working as intended and documented. If you wish, you could open an
'enhancement request' to have this behavior changed. To do so,
just follow the instructions included in my last update.
_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
[email protected]
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Pommier, Rex
Sent: Tuesday, September 13, 2016 4:11 PM
To: [email protected]
Subject: Re: IDCAMs DEF AIX authorization
Dave,
First of all, I agree with you that the programmer shouldn't have been able to
relate the AIX to the base cluster with only having read access to the base.
But that being said, since they could relate them, why couldn't they run the
BUILDIX command? The BUILDIX doesn't update the base cluster, does it?
Wouldn't read access to the base also have allowed the job to use that data to
build the AIX? Or does the BUILDIX somehow update the base?
Rex
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Jousma, David
Sent: Tuesday, September 13, 2016 12:08 PM
To: [email protected]
Subject: Re: IDCAMs DEF AIX authorization
Steve, the user tried to do the build index, but failed on lack of access S913
as he should have. The user *should* have then deleted his AIX, but didn’t,
and left it hanging out there. I suspect that the error was unintentional, as
our application dataset naming conventions here, leave a little to be desired.
*.TAT.* is test, *.PAT.* is PROD for this particular business application. It
is my guess, that the user forgot to change the PAT to TAT in the RELATE
portion of the DEF AIX.
_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President [email protected]
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Steve
Sent: Tuesday, September 13, 2016 11:51 AM
To: [email protected]
Subject: Re: IDCAMs DEF AIX authorization
The challenge you will have is that the user in question had authority to build
the AIX and the PATH but did not do the BUILD. And he could read the PRIMARY
KSDS.
This is an apples and oranges discussion or a Catch-22.
-----Original Message-----
From: "Roach, Dennis" <[email protected]>
Sent: Tuesday, September 13, 2016 11:45am
To: [email protected]
Subject: Re: IDCAMs DEF AIX authorization
Since it can, and did, cause a production outage, I voted for it.
I would think that a production outage would rate higher than a medium priority.
Dennis Roach, CISSP, PMP
AIG
IAM Access Administration – Consumer | Identity & Access Management
2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019
Phone: 713-831-8799
[email protected] | www.aig.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Jousma, David
Sent: Tuesday, September 13, 2016 9:09 AM
To: [email protected]
Subject: Re: IDCAMs DEF AIX authorization
I did open an RFE for this, if anyone wishes to vote on it, here is the info.
--------------------------------------------------------------------------------------------------------------------------
Notification generated at: 13 Sep 2016, 10:06 AM Eastern Time (ET)
ID: 94515
Headline: Add SAF check on DEF AIX for
RELATE Cluster
Submitted on: 13 Sep 2016, 10:06 AM Eastern Time (ET)
Brand: Servers and Systems Software
Product: z/OS
Link:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=94515
_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President [email protected]
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Jousma, David
Sent: Tuesday, September 13, 2016 9:49 AM
To: [email protected]
Subject: Re: IDCAMs DEF AIX authorization
Steve,
That’s what I am seeing, and IBM just confirmed it. I guess all we can do is
give the contractor a slap on the hands, and move on.
IBM comments:
Basically, authorization checking is done against the AIX being defined (ALTER
access to the AIX cluster name as shown in the table above) not the VSAM
dataset the AIX relates to. Checking against the related VSAM cluster will be
done when accessed by BLDINDEX.
So, this is working as intended and documented. If you wish, you could open an
'enhancement request' to have this behavior changed.
_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President [email protected]
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Steve
Sent: Tuesday, September 13, 2016 9:33 AM
To: [email protected]
Subject: Re: IDCAMs DEF AIX authorization
AS I remember, DEF AIX and PATH only operate in the CAT. The BLX would to the
extract to the AIX
-----Original Message-----
From: "Jousma, David" <[email protected]>
Sent: Tuesday, September 13, 2016 9:19am
To: [email protected]
Subject: IDCAMs DEF AIX authorization
All,
I've got a PMR open with IBM asking the question, but thought I'd also pass
this by the brain trust on this list. We recently had an off-shore contractor
do a DEFINE AIX for a TEST dataset name, but RELATEd it to a PROD dataset name.
The process was allowed surprisingly. Contractor only had read access to
prod dataset. The subsequent BLDINDEX did fail with security violation as
expected. Nightly processing of that prod file failed however due to the
empty AIX. Seems like DEF AIX should have been disallowed if the user didn't
have the appropriate access for what it was related too?
Dave
The information contained in this message is confidential, protected from
disclosure and may be legally privileged. If the reader of this message is not
the intended recipient or an employee or agent responsible for delivering this
message to the intended recipient, you are hereby notified that any disclosure,
distribution, copying, or any action taken or action omitted in reliance on it,
is strictly prohibited and may be unlawful. If you have received this
communication in error, please notify us immediately by replying to this
message and destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
