Rob,
Proper config and usage of adopted authority is the object is set to *owner, not *user.
*user really doesn't buy you anything.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, September 18, 2014 12:05 PM
To: Midrange Systems Technical Discussion
Subject: RE: [Bulk] RE: QSTRUPPGM issues
Paul,
I have a third party app. It says 'use adopted authority yes'. But it doesn't change it from *USER to *OWNER. To me, this is perfect. What this allows you to do is change someone's initial program to *OWNER. Then all programs called, if they have use adopted authority yes set will run under that profile. This is the best way, for 5250 applications, to use program access only. Look at it this way. They could be locked out of the data but the programs would have the appropriate authority needed. Use adopted authority yes basically passes the initial program's authority to pass down through the list. This is the best way a vendor could do it. I think it's great.
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: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 09/18/2014 10:16 AM
Subject: RE: [Bulk] RE: QSTRUPPGM issues
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Rob and Mark,
All good points.
I recently reviewed one of my 3rd party apps, 30,000 pgms ALL set to run
under adopted authority, all objects owned by QPGMR, and ALL objects
PUBLIC *change, wide open.
Trying to change authority on 3rd party apps is like starting WWIII, if
you change it, your maint contract is void.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Mark S Waterbury
Sent: Thursday, September 18, 2014 10:08 AM
To: Midrange Systems Technical Discussion
Subject: Re: [Bulk] RE: QSTRUPPGM issues
Paul:
If you just wanted QSTRUP to run "as" QSECOFR you could just change the
QSTRUPJD to specify user profile QSECOFR instead of QPGMR. But I would
not recommend that approach.
My suggested approach creates a second "start up" program that performs
only those actions that require QSECOFR to do them, so your existing
QSTRUPPGM can remain "as is" and continue to run under QPGMR.
Also, in general I agree that you normally do not want "a bunch of jobs or
programs" running "as QSECOFR" ...
In this case, when you do have a requirement to perform some tasks that
need QSECOFR authority, you now have a way to do that, and it is
"documented" (e.g. for the auditors) since you can show the subsystem
description for QCTL, and the autostart job entries, and show the source
code for the QSTRUP2 program (in this example).
HTH,
Mark S. Waterbury
On 9/18/2014 10:01 AM, Steinmetz, Paul wrote:
Mark,
To make a long story short, the instructions below basically has QSTRUP
run as QSECOR instead of QPGMR, correct.
This would solve many issues for me.
However, from a security stand point we should NOT be running jobs as
QSECOFR, correct.
I just finished my 4-day extended security training course.
Paul
--
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:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
