Re: SBMJOB adopted authority...

On 20-May-2016 07:45 -0500, Rob Berendt wrote:

On 20-May-2016 07:33 -0500, Denis Robitaille wrote:

I don't know who told you that *public *use was bad for JOBD but,
in my mind, that is perfectly acceptable.

So,

So, after someone with all necessary authority has effected as setup:
crtusrprf omnipotent usrcls(*secofr) spcaut(*usrcls)
/* default or explicitly: */ aut(*exclude)
crtjobd secjobd user(omnipotent) aut(*use) /* pubaut=use */

it's perfectly acceptable that any user can do
SBMJOB CMD(CLRLIB LIB(PRODLIB)) JOBD(SECJOBD) USER(*JOBD)
SBMJOB CMD(CHGUSRPRF QSECOFR PASSWORD(HITHERE)) JOBD(SECJOBD)
USER(*JOBD)
My auditors tend to believe differently.
If someone "just has to" submit such a job it's done from a program
with adopted authority.

An actual test of the above setup should prove that any user can *not* do the later Submit Job (SBMJOB) command requests. The authority of the user submitting the job requires authority to the user that would start the submitted job; the request should fail with previously logged diagnostic msg CPD1616 "Not authorized to user profile &1." The authority to that User Profile (USRPRF) can not be from adopted authority; that is likely the problem for the OP, but I have no idea what is the alluded cpf1414 -- a transcription error.?.?

So yes, AUT(*YES) can be /perfectly acceptable/ for many job descriptions, because the ability to run the submitted job under another user is protected. Of course, for a properly secured system, resource security should include job descriptions, and default authority might best be *EXCLUDE [just as is the default for user profiles].