Re: DSPAUT OBJ('/QSYS.LIB') versus DSPOBJAUT OBJ(QSYS) TYPE(*LIB)

On 2/8/11 5:42 AM, John Earl wrote:

On Feb 7, 2011, at 2:37 PM, CRPence wrote:

A SWAG... is that POSIX standards are the fault for the difference
in requirements. IIRC the object [operational] authority *OBJOPR
enables viewing\accessing the data rights [data authority] to the
object natively, which is the first requirement of *USE since that
object right must exist to even know\test of any data rights. The
object [management] authority *OBJMGT as a requirement for
displaying authority via an IFS [non-native naming] API is
presumably an attempt to mimic similar limitations that would be
imposed on a *nix system.?

This SWAG matches my experience - and kind of tracks with the way a
CRTDUPOBJ command works. You'll notice that you can CPYF a file with
just *USE, but you must have *USE + *OBJMGT in order to CRTDUPOBJ.
This is (at least in part) because CRTDUPOBJ must access the security
authorization description part of the file in order to completely
duplicate the object and a CPYF does not (because it does not
duplicate the authorities to the new file).

FWiW there was actually a "requirement" that for the effect of CPYF CRTFILE(*YES) [and I think CPYFRMQRYF as well; from the first file named in the OPNQRYF], the object authorities should be duplicated from the FROMFILE just as how the existing authorities are duplicated from the OBJ() to the NEWOBJ() on a CRTDUPOBJ request. I recall arguing against that for a variety of reasons [since the intent is so easily defeated], but as I recall the change was made long ago such that the authorities were copied. Thus I expect you will find the authorities are indeed being transferred\duplicated from the FROMFILE() to the TOFILE() when the CRTFILE(*YES) actually effects a[n effective] CRTPF.

I believe several releases later a new requirement [reported as a defect IIRC; I did not search for an APAR on the IBM site] came about to prevent the CPYF from copying a file when the requesting user had no ability [lacking the authority] to assign a private authority to another user due to the current user [or its group profile] having become the owner. With the prior revision to the CPYF, the granting of authority had all been done via adopted authority, so a CRTDUPOBJ that would fail would still complete using CPYF [and depending on the parameters specified, be _equivalent_ to the CRTDUPOBJ]; effectively only the ability to "read" the data and to create the target file were used as the authority criteria to perform the copy, without any regard to the ability to assign the authorities.

I do not recall the outcome from that scenario, being an "I told you so" moment, I could best argue for continued use of adopted authority so as to avoid rehashing the same arguments against ever having made the earlier change to the CPYF [to duplicate the authorities]. I really doubt that the outcome was a change to require *OBJMGT for the user on the FROMFILE() for when creating a new file was the effect, but if it had been, surely there would have been an entry in a MTU for having changed the behavior such that copy file requests that had been working since the S/38 would start failing. Avoiding that outcome of breaking existing code, was the reason adopted authority was used to implement the first change.

Regards, Chuck