Re: [Bulk] RE: QSTRUPPGM issues

Rob,

I disagree...

I'd much prefer a 3rd party app to have USEADPAUT(*NO) USER(*OWNER) and
have a application specific (set of) user profile(s) own the applications
programs.

Adopting & propagating authority in the initial program is a bad idea from
what I've read and seen. Not to mention it breaks down if you've got
multiple 3rd party apps.

Charles



On Thu, Sep 18, 2014 at 12:04 PM, <rob@xxxxxxxxx> wrote:

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.

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


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