Unconditionally allow renames of datasets within DFDSS dump dataset

If I do a DFDSS (ADRDSSU) backup of a dataset such as SED.JCL, and then take that backup to another site that doesn't have the HLQ of "SED", but the user (SCOTT) does have access to a HLQ of "SCOTT" and he then attempts a restore, like this:

RESTORE DATASET( -
...
RENAMEU((SED.**,SCOTT.**))

he gets the following errors:

22.50.37 JOB06585 ACF99913 ACF2 VIOLATION-00,09,AIMI080,SEASIK,SED.JCL,N/A

ADR402E (002)-AUTH (16), AUTHORIZATION CHECK FAILED FOR DATA SET SED.JCL, ON VOLUME SEASIK, 4

DFDSS has gone out of its way to check that the user has access to "SED", even though the user is neither reading nor writing any dataset with an HLQ of SED. Instead, he is reading a DFDSS dump called SCOTT.DFDSS which he ftped from the internet, and is then attempting to write to another dataset called SCOTT.JCL, both of which he has access to.

If the user uses the "ADMINISTRATOR" keyword, then the check for the "SED" HLQ is omitted. The trouble is that SCOTT may not have access to that keyword, and nor should he need access to that keyword.

If this RACF check against "SED" is meant to provide security, then it is unfortunately a case of false security. Because so long as he has RACF access to the DFDSS dataset (regardless of whether the dataset was obtained from the internet, or is a local backup), then he does in fact have read access to all the datasets on that backup. An unprivileged DFDSS clone could be written to retrieve the files with no security check. Or, even more practical, is a small, unprivileged program like this:

http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/pdpclib/dssrenam.c?view=markup

(also attached to this request)

which can rename all the "SED" references to "SCOTT", or rename "SECRET" to "SCOTT", or rename "PROD" to "SCOTT". It does this by direct manipulation of the DFDSS dump dataset, which SCOTT has access to, so that there are no "SED" references anymore, and all "security" has been bypassed. A normal (non-admin) DFDSS restore (exactly the same as above) will no longer get security violations, because "SED" is no longer visible, only "SCOTT" is visible.

I think giving people a false sense of security is dangerous. As such, I think that RACF check should be omitted, at least by default. If the sysprog wishes to change a default FALSE_SECURITY=NO to FALSE_SECURITY=YES, to do that additional RACF check in non-administrator mode, I guess that can be allowed, but I really don't think that option should be there at all, as it means that my "dssrenam" program will still be required (for eternity), to bypass that false security. I would rather retire the "dssrenam" utility.