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

They mean the user profile _in_effect_.  That means if you are using
program profile adoption, then it is the combined authorities of the
Signed on User and the Owner(s) of the adopting program(s) being
executed.

If you are using swapped profile, it is simply the authority of the
"Current" user.

jte 


--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

> -----Original Message-----
> From: security400-bounces@xxxxxxxxxxxx
> [mailto:security400-bounces@xxxxxxxxxxxx] On Behalf Of Dan
> Sent: Friday, November 11, 2005 8:23 AM
> To: Security400@xxxxxxxxxxxx
> Subject: [Security400] Program object's USRPRF(*USER vs.
> *OWNER) effect onauthorities 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@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/security400
> or email: Security400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/security400.
> 



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.