Re: System startup porgram and adopted authority

Thank you for the responses.

Maybe someone can enlighten me as to why if the program is owned by
QSECOFR and USRPRF(*OWNER) why is it running under QPGMR.

I am sure I have used this procedure in the past to provide additional
authority to a program.




Don Brown





From: "DrFranken" <midrange@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: 08/03/2018 05:42 PM
Subject: Re: System startup porgram and adopted authority
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



The points thus far have been good and accurate.

One thing not mentioned is that certain authorities are NOT adoptable.
As a consequence even owning the program by QSECOFR is not sufficient. A
common case I run into is the pieces that POWERHA requires to be
started. QPGMR can't do it and the needed authority cannot be adopted.

So I generally do a variation on the earlier suggestions in this thread
and with Jim's thinking try to box tight the use of higher authority. I
create a profile that has no password and no command line ability. I
grant authority to QPGMR to use that profile. In the startup job I
submit the program with the needed steps using the profile.

One thing I've done is for steps that need to be completed before the
startup job continues is to create a data are just before submitting the
second task. At the end of that task the data area is deleted. Meanwhile
the primary startup job loops waiting for the data area to disappear.

Clearly not the only way to do this but it has worked well.

- Larry "DrFranken" Bolhuis

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

On 3/8/2018 12:34 AM, Jim Oberholtzer wrote:

Another point would be over all security. That job description is well

known. If it's changed to a high authority profile, you leave a potential
security hole in plain view that can be exploited in ways you would not
intend.

A call or the submitted job would be significantly more secure. Even

then, that job should check itself to be sure its running in an
appropriate environment and time.

Jim Oberholtzer
Agile Technology Architects

On Mar 7, 2018, at 5:05 PM, Steinmetz, Paul <PSteinmetz@xxxxxxxxxx>

wrote:

Don,

I have similar issues with QPGMR on QSTRUP.
One of the things I've done is the processes that need be started by a

certain user is to do SBMJOB with that user.

This also solve the authority issue.
Keep in mind, if you start jobs with QSECOFR, if you ever need to view

any of those jobs, you need to be a user with QSECOFR authority, or
equivalent.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of

Don Brown

Sent: Wednesday, March 07, 2018 6:54 PM
To: Midrange Systems Technical Discussion
Subject: System startup porgram and adopted authority

System is V7R3
When the system IPL's the startup program specified in the system value

QSTRUPPGM is run.

The job is started with job description QSYS/QSTRUPJD and by default

this job description has user profile QPGMR

I had always changed the startup program to be owned by QSECOFR and use
USRPRF(*OWNER)

I believed the program would then adopt QSECOFR authority.

I am looking at a joblog for the startup program where an error

occurred as the user QPGMR was not authorised to the CHGNFSEXP as the
profile does not have IOSYSCFG special authority.

This is true, QPGMR does not have IOSYSCFG and QSECOFR does have

IOSYSCFG

My thought is to change the user in the QSYS/QSTRUPJD to QSECOFR.

But I do not understand why the program is not running with QSECOFR

authority ?

Any suggestions from the group ?

Don Brown



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