Re: Issues with Adopted Authority

​​
USEADPAUT is poorly named...

In order for an application to "adopt authority", USRPRF must be *OWNER.

Your ERP system doesn't adopt authority, it uses whatever might alright
have been adopted by something outside the ERP.

USEADPAUT should have been named "Allow adopted authority (to propagate)"

With USRPRF(*OWNER), you can give JSMITH *USE to PGMXYZ and PGMXYZ adopts
the authority needed to change it's files. It doesn't matter how JSMITH
calls the program, rather than saying JSMITH must use this menu to call
PGMXYZ.

Carol's books get more into it, but here's an short article...
https://www.mcpressonline.com/security/ibm-i-os400-i5os/adopted-authority-friend-or-foe
"The default value for the User profile parameter is *USER, which means
that the program will not adopt authority. Changing it to *OWNER sets the
attribute so the program will adopt authority."
" I configure the application programs to adopt—typically all of them, with
the exceptions such as ones previously described. "

Charles




On Tue, May 29, 2018 at 6:12 PM, Rob Berendt <rob@xxxxxxxxx> wrote:

Our ERP system comes shipped from the vendor with USEADPAUT(*YES) on all
programs so that you can set up an initial program and use "application
only access", if you want to.
And since IBM ships QCMDEXC and other programs this way I think this is
the way to go.

If you're going to use CHGPGM on all programs for *owner then why not do
it for useadpaut?


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Charles Wilt" <charles.wilt@xxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: 05/29/2018 03:45 PM
Subject: Re: Issues with Adopted Authority
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



My personal preference is to compile (change) every program to
USRPRF(*OWNER) and have them all owned by the APPOWN user profile. APPOWN
would have *CHG authority to the files/tables.

This way every program adopts the authority needed, rather than depending
on some previously adopted authority from earlier in the call stack.

Charles



On Tue, May 29, 2018 at 1:24 PM, DrFranken <midrange@xxxxxxxxxxxx> wrote:

If you are going down this path the routing program I think is the right
direction.

- Larry "DrFranken" Bolhuis

www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.


On 5/29/2018 3:03 PM, Marc Rauzier wrote:

Le 29/05/2018 à 16:52, Joe Hatchell a écrit :

The call stack is
lost and therefore they have no authority to the objects needed to run
the
program.

I solved a similar issue by writing a program which is invoked in the
routing entry of the batch subsystem in place of QSYS/QCMD program.
The program I wrote does adopt owner authority. In fact, it is a bit

more

complex but this is the principle.

Marc

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD