Re: IBM objects with modified authority and v5r2 --> v5r4 upgrade

The OS output file feature can CRTDUPOBJ of those files to effect creation of the named OUTFILE(), even if\when the user is not authorized to do so. That is, the authority for *PUBLIC need not be any more than *USE which would allow DSPFFD and DSPFD for a user to learn the details of the file and fields, to understand how to use the files. An ordinary user should IMO *not* be able to actually change the attributes of the [model output] files. When a command that uses the model outfile runs and the named OUTFILE() is created, the user that issued that command [normally] gets *OWNER rights to the object that was created, so AUT(*CHANGE) for *PUBLIC would be moot.

The OP had the authority customized to grant sufficient authority for the /application profile/ to perform its own CRTDUPOBJ, rather than allowing the outfile-command perform the request. Applications often require their own CRTDUPOBJ to perform customizations; e.g. create a duplicate of the model, then CHGPF SIZE(*NOMAX) for an upcoming request to DSPOBJD *ALL/*ALL for which the model file has SIZE(10000). For the case of *PUBLIC having even AUT(*CHANGE), *CHANGE authority is still insufficient to enable CRTDUPOBJ without using adopted authority [in the application]; i.e. *OBJMGT is required above & beyond *USE to the object being duplicated.

If the various /model output files/ are shipped as part of the OS with *CHANGE as the authority for *PUBLIC, that means *any* user can issue a variety of requests that change the object; e.g. CHGPF QSYS/QAFDMBRL TEXT('I just hacked this file') SIZE(1 1 1) Certainly if true, that is a bad thing?

As /model/ files, these can be and are often customized. However I would likely not grant a private authority if that private authority was being propagated to every copy made by the OUTPUT(*OUTFILE) invocations. Instead I might create a program to duplicate the file. If duplicates of the files are made into a library from which applications would make duplicates, system Change Management requires that those files be created [and customized] again from the copies in QSYS or QSYS29xx after an upgrade [or in the unlikely event the model file were replaced in a PTF].

Regards, Chuck

Carel Teijgeler wrote:

I think the authority *CHANGE for user *PUBLIC is understandable on
those files.

The commands using those IBM supplied files, which originally do not
have any members, have to duplicate their associated output file and
add a member to it, before filling it with data.

It is also common practice and advised not to change the default
settings on IBM supplied objects, so I wonder why this setup of
authority, when the commands used create a copy at the moment the
output file does not exist. But then, I do not know the philosophy
behind this setup.

Instead I would have created my own master (base) files for my
application, based on the IBM supplied files.*

CRPence wrote:

Charles Wilt wrote:
<<SNIP>>

After a v5r2 --> v5r4 upgrade on our QA system QAFDMBRL was back
to the IBM default of *PUBLIC change with no additional private authorities.

That suggests *PUBLIC has *CHANGE? Hmmm... that seems excessive;
i.e. that authority would allow any *peon user to issue a CHGPF QSYS/QAFDMBRL given that user has access to a command line.?

<<SNIP>>