× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 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.