Re: OA49446 changed RACF behavior for ALIAS, PATH, and AIX

2017-09-21 Thread Paul Gilmartin 
On Thu, 21 Sep 2017 16:39:41 -0400, John Eells wrote:
>
>"Code is added to require SAF ALTER authority to the entry name when
>defining an alias related to a nonVSAM or generation data set, or a VSAM
>PATH or AIX. SAF ALTER authority is required to the entry name when
>defining an ALIAS when the related name is for a nonVSAM or generation
>data set.  SAF ALTER authority is required to the entry name when
>defining a VSAM PATH or Alternate Index (AIX)."
> 
I have used DEFINE ALIAS (nonvsam) and DEFINE PATH (vsam) to manage
durable handles where the RELATED data set names are qualified with date
and version components.  Is this affected?  (Not defining alternate indices.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OA49446 changed RACF behavior for ALIAS, PATH, and AIX

2017-09-21 Thread John Eells 

Correction: A check was added for defining data set aliases:

DEFINE ALIAS(NAME(dataset1) RELATE(dataset2))

...but not for user catalog connector aliases:

DEFINE ALIAS(NAME(hlq) RELATE(usercat))

Note that the new checks are in IDCAMS DEFINE.  From the PTF:

"Code is added to require SAF ALTER authority to the entry name when 
defining an alias related to a nonVSAM or generation data set, or a VSAM 
PATH or AIX. SAF ALTER authority is required to the entry name when 
defining an ALIAS when the related name is for a nonVSAM or generation 
data set.  SAF ALTER authority is required to the entry name when 
defining a VSAM PATH or Alternate Index (AIX)."


John Eells wrote:

Your post confused me, so I just verified that my understanding was
correct.

The checks for PATH and AIX were added to the base name check, and do
not replace it.  Also, I am told nothing was added for ALIAS.

Pinnacle wrote:

I'm looking at the HOLDDATA for OA49446.  RACF was changed to do
authorization checks against ALIAS, PATH, and AIX names instead of the
base names.  There was no migration path specified to get to this new
RACF state, except for a chicken switch
STGADMIN.IGG.CATALOG.SECURITY.CHANGE.  If you have read access to that
FACILITY class profile, you use the "old" method and not this new
method.  Did everybody just define the profile with UACC(READ)?  That
seems easier than taking all the ICH408I's that could result the other
way if you use dataset ALIASes and AIX's.  What did you guys do for this





--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OA49446 changed RACF behavior for ALIAS, PATH, and AIX

2017-09-18 Thread John Eells 

Your post confused me, so I just verified that my understanding was correct.

The checks for PATH and AIX were added to the base name check, and do 
not replace it.  Also, I am told nothing was added for ALIAS.


Pinnacle wrote:

I'm looking at the HOLDDATA for OA49446.  RACF was changed to do
authorization checks against ALIAS, PATH, and AIX names instead of the
base names.  There was no migration path specified to get to this new
RACF state, except for a chicken switch
STGADMIN.IGG.CATALOG.SECURITY.CHANGE.  If you have read access to that
FACILITY class profile, you use the "old" method and not this new
method.  Did everybody just define the profile with UACC(READ)?  That
seems easier than taking all the ICH408I's that could result the other
way if you use dataset ALIASes and AIX's.  What did you guys do for this


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OA49446 changed RACF behavior for ALIAS, PATH, and AIX

2017-09-18 Thread Mark Jacobs - Listserv 
YMMV, but we've been running with that APAR applied for well over a year 
without any fallout and didn't define that RACF profile.



Pinnacle 
September 18, 2017 at 2:04 PM
I'm looking at the HOLDDATA for OA49446.  RACF was changed to do
authorization checks against ALIAS, PATH, and AIX names instead of the
base names.  There was no migration path specified to get to this new
RACF state, except for a chicken switch
STGADMIN.IGG.CATALOG.SECURITY.CHANGE.  If you have read access to that
FACILITY class profile, you use the "old" method and not this new
method.  Did everybody just define the profile with UACC(READ)?  That
seems easier than taking all the ICH408I's that could result the other
way if you use dataset ALIASes and AIX's.  What did you guys do for this
"fix"?

Regards,
Tom Conley

--



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN