SBMJOB and adopted authority

[GV]

Is there a way to use adopted authority when submiting jobs?, other
than manually changing the job to run under a different user?

[René H. Hartman]

It can be done, but requires quite some effort. Back in 1999, I
redesigned the security for a client's system based on adopted authority
(and authorisation lists for QDLS and the IFS, since adopt doesn't work
there).

It required the building of a modified SBMJOB command, that would strip
all libraries off the liblist, and store the request-to-be-submitted
with all relevant info like liblist and adopting user in a keyed dataq.
It would then submit a call to a pgm that would fetch the dataqueue
entry by key and use the info to set adoption for the original user,
rebuild the liblist, and execute whatever was in the request data. This
has been working since day 1 without a single problem.

It took me about three months to design, develop, test and implement the
mechanism, where the majority of the time was spent on cracking the
problem of running batch jobs.

Regards,
René
--

"GV" <babu...@att.net> schreef in bericht
news:f22f3bb1.04092...@posting.google.com...

[Jan Willem de Lange]

"GV" <babu...@att.net> schreef in bericht
news:f22f3bb1.04092...@posting.google.com...

> Is there a way to use adopted authority when submiting jobs?, other
> than manually changing the job to run under a different user?

You can try the method René suggests, or if it should be quick and dirty
create your own SBMJOB command with a Command Processing Program that adopts
the required authority and uses (inside) the "real" SBMJOB.
Four lines of code and a security exposure (if you do it wrong).
Jan Willem

[René H. Hartman]

"Jan Willem de Lange" <janwille...@nospam.tiscali.nl> schreef in
bericht news:4151b130$0$44065$5fc...@dreader2.news.tiscali.nl...

Won't be quick and dirty still, but very likely a security hole. Faking
the SBMJOB is not simple, if you look at the amount and nature of
parameters. Since you cannot control what parameters are used in
commercial software (that you can not modify) you have to make sure you
really are compatible. There's more than meets the eye...

Regards,

[Brian]

Here is a very easy solution.

Create a routing program that adopts the needed authority. Here's a minimum
routing program that will work:

pgm
call qcmd
endpgm

Add a routing entry to a new or existing subsystem to invoke your routing
program.

This is the absolute minimal implementation. QCMD fetches the request data,
typically the CMD() parameter from SBMJOB command and runs it. Because your
adopting program is calling QCMD, you have adopted authority for the batch
job.

If you need to adopt authority from various profiles, create more routing
programs, and routing entries with routing data specified. Use routing data
on SBMJOB command to select the appropriate routing program.

You might want to add some security features. Who will be allowed to run a
job using your new routing program? What commands will your routing program
be willing to run?

"GV" <babu...@att.net> wrote in message
news:f22f3bb1.04092...@posting.google.com...

[Techboy]

Why do you want to do this? There may be a simpler solution.

For excample, If you are running interactive adopt and need to have
submitted jobs adopt also, you can have the first program that runs in batch
adopt, but secure it from *PUBLIC use, and only authorize the end user (or
Group) to that program.

"GV" <babu...@att.net> wrote in message
news:f22f3bb1.04092...@posting.google.com...

[Techboy]

Brian, your caveats at the end are very important. If using a routing
program, make sure you only grant authority to the authorized user of this
program. I have seen some popular banking software where the routing program
is there, and adopts, but is *PUBLIC *USE... a VERY BAD THING...

"Brian" <no.spam.for@me> wrote in message
news:41520d51$0$80691$a186...@newsreader.visi.com...

[GV]

Thanks,

Your suggestion worked perfectly. Created a group with *use
authority to the programs

GV