Re: Job submitted in Qstrup

["Mark S. Waterbury" <mark.s.waterbury@xxxxxxx>]

Hi, John:

Thanks for the detailed reply.

I do not advocate using QPGMR as a group profile, but I find that many
AS/400 shops do use it as a "programmer" group profile (right or wrong)...
So, I was just pointing out some of the "caveats" of doing it that way...
;-)

I agree with your proposed solution (explained in detail below).

Cheers,

Mark

----- Original Message -----
> From: "John Earl" <john.earl@xxxxxxxxxxxxxxxxxx>
> To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
> Sent: Monday, November 03, 2003 4:00 PM
> Subject: RE: Job submitted in Qstrup
>

> > If you give QPGMR *USE authority to the GAL profile,  then
> > any user who belongs to the group QPGMR will also have authority
> > to submit jobs "as" GAL...
>
> True, and I like your adopted authority approach better
> (though I would create a profile other than QSECOFR to
> adopt).  But this reply begs the question, "Why would you
> ever make QPGMR (or any other IBM profile) a group profile?"
>
> There are just so many ways to assume QPGMR's identity, if
> it is a group profile, or worse yet if it is a production
> object owning profile, there are likely a number of ways
> that people can compromise your system by acquiring QPGMR's
> rights.
>
> And the reverse is true as well, If there are a number of
> people who belong to the QPGMR group, then these folks can
> get into some of the internal IBM routines (Like QSTRUP, for
> example) and mess things up in the OS.  Either way, I think
> it's a bad idea to mix IBM profiles with your applications.
>
> So, to give a more appropriate answer to the original
> question, I would create a tiny CL program that performed
> the two SBMJOB's, and compile that program to run under
> GAL's authority.  Then give QPGMR just *USE authority to the
> program.
>
> That's secure, simple, and minimizes QPGMR's reach into your
> application.
>
> But that's JMHO,  :)
>
> jte
>