Re: Authority annoyances, continued...

Dan,

I agree with the poster who asked why this was different/better than
just creating an adopted authority program.  It can be significantly
less secure than an adopted authority routine.

> Create a user on the system (eg. BACKUPUSER) with no password
(password
> *NONE). Ensure this user has the required authority to do the back
up. A
> good way to achieve this is to put the user into the QSECOFR group,
make the
> group the owner of all objects created by this user.
>
> Create a job description that will be used to submit the back up job
to
> batch. Ensure that the USER parameter of the job description
specifies the
> new user (eg. USER(BACKUPUSER)). Any job submited to batch using
this job
> description will then run under the new user profile.

This last line may be much truer than you wish.  On a security level
30 machine, this JOBD would be usable by any user, for any purpose
they desire, unless you specifically restrict access to the JOBD.

If you choose this route, please be sure to secure the JOBD to *PUBLIC
*EXCLUDE and then specifically give the user who will be submitting
this job *USE authority to the JOBD.  This will prevent other users
from misappropriating this JOBD.

It may not prevent the original user from mis-using this JOBD though.
Once you give them authority to use the JOBD, it may be difficult or
impossible to control what they use the JOBD for.

An adopted authority routine that does a very specific thing, and
adopts the necessary authority for a finite period of time can provide
a much more secure route to your destination..

jte


--
John Earl - VP & CTO
The Powertech Group
253-872-7788
johnearl@powertechgroup.com
www.powertechgroup.com