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


  1.  Home
  2. MIDRANGE-L
  3. December 2019

Re: sbmjob user(xxxxx)

so may have stumbled upon a much simpler solution where I may have been
unclear about not needing tightened security with new SFTPUSER user profile.

in our test layer, i simply copied a basic user profile to a new SFTPUSER
profile.
Both are under same group profile and owned by *GRPPRF.

I can easily submit the job from basic user profile to user(SFTPUSER) and
this accomplishes what I need without dinking with security.
I guess what I failed to mention is that SFTPUSER does NOT need to have
enhanced security around it compared to basic user profiles.

Jay

On Fri, Dec 27, 2019 at 9:03 AM DrFranken <midrange@xxxxxxxxxxxx> wrote:

I think where Jim was going is the SBMJOB command goes into that CLP
that adopts authority. This way the job user doesn't have authority on
their own to submit jobs with other user's authority. However when that
program is called it adopts enough authority to be able to submit the
job under another profile. So that CLP is primarily just one command
SBMJOB. The input parameters are basically just whatever you need to
fill out the SBMJOB such as date ranges or other values.

In theory you could also make it very generic and have the parameter be
the entire command to run. But, um WARNING WARNING WARNING that is a
massive security hole!! Because now they could run PWRDWNSYS for example
or my favorite command GIVBIGRAIS.

- Larry "DrFranken" Bolhuis

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

On 12/27/2019 8:49 AM, Jay Vaughn wrote:
jim thank you...

we don't want to necessarily just adopt the authority of another user, we
literally need it to run under the "other" user profile...

the reason for this is we have a pgmA that is a clp that runs an sftp
process.

When pgmA is invoked and ran, we don't know if this particular sftp will
be
password or ssh key auth.

But we do know if it will be sshkey or password when we code the sbmjob
in
our application.
And if it is ssh key then we want to sbmjob user(sftpuser). (sftpuser is
the sole userprofile for holding all the ssh keys.)

jay


On Fri, Dec 27, 2019 at 8:43 AM Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx>
wrote:

Jay:

I’m not certain what the use case is here, but I’ll bet you don’t really
want to give everyone that authority, or at least based on your note a
limited number.

The best way to accomplish this in my view is with an adopted authority
CLP wrapper.
Take in parms that you need for the job, and craft a SMBJOB command as
needed. Create your own command if it makes sense to do so.

That way you can accomplish your goal and maintain some level of
control.
I’ve even seen those programs encode a journal entry to a user journal
in
order to memorialize the job for later audit.

Jim Oberholtzer
Agile Technology Architects



On Dec 27, 2019, at 7:25 AM, Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:

so we have a need to submit a job under another specific user profile.

what is the best/cleanest method for implementing this?

obviously we can just specify the new user on the sbmjob user() parm,
but
what about each individual user profile that may do the sbmjob, what is
the
best/cleanest way to maintain those user authorized to the sbmjob
user()
user profile?

tia

jay
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
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: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
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: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
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: https://amazon.midrange.com


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.