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

[CRPence <CRPbottle@xxxxxxxxx>]

  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>>