Program object's USRPRF(*USER vs. *OWNER) effect on authorities required to run certain things.

I think I know the answer to this, but because it is really tough for
programmers to test authority issues in this environment, I would like to
get a sanity check before putting my mods into production.

Had a problem this morning with a new program I put in production where a
user got an authority error where the program tried to run an ADDPFM on a
data file. The program actually did a CHKOBJ AUT(*CHANGE) on the file (and
passed that check), but I found out the hard way that ADDPFM requires
*OBJOPR, *OBJMGT, or *OBJALTER authority, and *CHANGE doesn't include those.

Anyway, the temporary quick fix was to change the file's *PUBLIC authority
to *ALL. But I want to revert it back to *CHANGE, which is the standard here
for production files, and change the program to USRPRF(*OWNER), which would
then, supposedly, have the necessary authority to execute the ADDPFM. The
*OWNER of the program object in question also owns the file.

The documentation for command ADDPFM doesn't mention anything about
authority requirements, so I go to the CLRPFM doc and see that it refers to
_user_ required to have the *OBJOPR, *OBJMGT, or *OBJALTER authority. (See
RANT below.)

QUESTION: Do they really mean to imply the _user profile_ in effect at the
time the command is being executed, and not the signed-on _user_?

TIA, Dan

<RANT /ON> On V5R2, the documentation seems to be extremely inconsistent
regarding including the authorities required by commands. The online help
for CHGPFM has it, but CLRPFM and ADDPFM do not. The InfoCenter docs for
CHGPFM and CLRPFM has it, but not for ADDPFM. Had to go to "Appendix D.
Authority Required for Objects Used by Commands" in the Security Reference.
<RANT /OFF>
_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) mailing list
To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.