Problem to restore datasets with revoked userid
Article ID: 44634
Updated On:
Products
Issue/Introduction
Problem:
The customer is converting from HSM to CA Disk but cannot restore data sets that have a high level qualifier from a revoked user.
There are messages for the revoked userid and the Restore finishes with RC=8:
ICH408I USER(uuuuuu ) GROUP(xxxx ) NAME(yyyyy zzzzz )
LOGON/JOB INITIATION - REVOKED USER ACCESS ATTEMPT
and
ADSSI001 3617 IGD308I DATA SET ALLOCATION REQUEST FAILED -
ADSSI001 3617 RACF FUNCTION: RACDEF FOR
ADSSI001 3617 DATA SET: uuuuuu.dsname WITH RETURN CODE 08 REASON CODE 4C
ADSDM069 2433 =========================================================
ADSDM069 2433 AN SVC 99 ERROR HAS OCCURRED IN -- DYNAMIC ALLOCATION
...
Environment:
CA Disk, DFHSM
Cause:
DIAGAUTHy diagnostics will indicate that all the Disk RACROUTE calls passed until SVC99 is called to actually allocate the new data set.
At this time, RACF will deny access due to the revoked userid which is the owner of the profile/data set based on the RACF definitions.
Disk cannot override this function.
Resolution:
Set USE_RESOWNER to NO in IGDSMSxx to solve the problem.
Setting USER_RESOWNER to NO in SMS will tell SMS to use the userid of the initiator of the allocation request rather than the owner of the resource.
IPL the test system to pick up the new IGDSMSxx value of USE_RESOWNER(NO) and verify that this resolves the issue.
Additional Information:
The RACF RESOWNER value, based on the high-level qualifier of the data set name, is the default used to check authorization to use management and storage classes.
Another way to check this authorization is to use the user ID that is allocating the data set.
This prevents the problems that can occur with restoring or recalling data sets that have a protected storage class and management class, and that are owned by users whose user or group IDs have been revoked.
As the Disk security trace shows, Disk does not make the security call that results in the allocation failure.
It is SMS itself that is making the call during allocation and the USER_RESOWNER setting determines which userid is checked.
With USER_RESOWNER(YES), SMS is going to check the real owner and the security call will fail if that owner has been revoked.
With USER_RESOWNER(NO), the userid of the initiator of the allocation, in this case CA Disk, is checked.
Bottom line here is there is nothing CA Disk can do because it is SMS that is making the security call and your SMS settings determine how that call will be made.
Environment
Component:
Feedback
