RE: Problems with adopting authority

Generally it's good to avoid the use of IBM profiles in production
applications and build your own profiles instead.  The reasons vary wildly,
but some recent examples that I recall are:

1) Profiles filling up - Some releases back there were a rash of problems
where profiles were filling up, meaning that they owned too many objects and
there wasn't room for the OS to store the fact that a new object was created
that QSECOFR or QPGMR owned.  This problem hit a lot of shops where the
standard was to have everything owned by QSECOFR or QPGMR.  Once the
profiles filled up it would halt production.  These two profiles were more
prone to problems than others because they already own so many pieces of the
OS. 

2) IBM Changed something - in V3R7 IBM changed the behavior of the *PGMR
class such that it no longer automatically received *SAVRST and *JOBCTL
special authorities.  In the process they also pulled those special
authorities from the QPGMR profile.  IMHO this was a good security move on
IBM's part, but many people who had relied on using the QPGMR profile as a
part of their production application got really ticked when their
applications broke.  If you rely on IBM profiles you are subject to the
whims of OS changes.  Better to build your own profile so that a change in
the OS does not necessarily change the way your application operates.  It
also separates the authority that you provide in your application from the
authority that IBM provides to OS functions.

3) QSECOFR is too important to be messed with.  If QSECOFR is disabled or
otherwise made inoperable (such as when it refers to a library in its
library list, and that library is deleted) (<--Been there, done that.), then
you can find yourself in a really tight spot.  Better to create your own
QSECOFR look-a-like and use it for security related stuff.  If you break
your look-a-like profile, you can always sign on as QSECOFR to fix it.  If
you break QSECOFR and you don't have a spare, you're in a tight spot.

These are just some reasons, I'm sure there are more.  For me what it boils
down to is that it is both prudent and inexpensive to create a QSECOFR clone
and save the real QSECOFR for emergencies.

jte 


--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxxxxxxx
www.powertech.com 
 

--
 

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> Sent: Monday, March 24, 2003 11:13 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: Problems with adopting authority
> 
> Why is it so much better to create a user profile with all the authorities
> of QSECOFR, and have the program owned by that user profile than just to
> have it owned by QSECOFR?
> 
> Rob Berendt
> --
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
> Benjamin Franklin
> 
> 
> 
> 
> qsrvbas@xxxxxxxxxxxx (Tom Liotta)
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 03/21/2003 06:25 PM
> Please respond to Midrange Systems Technical Discussion
> 
>         To:     midrange-l@xxxxxxxxxxxx
>         cc:
>         Fax to:
>         Subject:        RE: Problems with adopting authority
> 
> 
> Rob:
> 
> I'd try it this way...
> 
> 1. Leave owner as QSECOFR (or better, a *SECOFR but not QSECOFR).
> 2. Leave program as usrprf( *OWNER ).
> 3. Early in the program, switch to an authorized profile that can execute
> user profile changes.
> 4. Call QCAPCMD (or whatever) to do the work.
> 5. Then immediately switch back to whatever user was running the job
> (possibly QTCP).
> 
> This way, usrprf(*OWNER) has authority to switch both ways and the
> switched-to profile has authority to do the work without requiring adopted
> authority.
> 
> You should only need to create the one switched-to profile unless you also
> choose to create the alternative *SECOFR profile (a very good idea,
> avoiding QSECOFR).
> 
> Tom Liotta
> 
> midrange-l-request@xxxxxxxxxxxx wrote:
> 
> >   9. Re: Problems with adopting authority.
> >
> >IBM responded to my pmr.  Working as designed.  You cannot access a user
> >profile with adopted authority.  Via QCAPCMD, CL program or anything.
> >
> >Suggestion:  Grant QTCP access to that user profile.
> >
> >Scares me at first, but the more I study that it sounds reasonable.  But
> >I'd appreciate comments from y'all.
> 
> --
> --
> Tom Liotta
> The PowerTech Group, Inc.
> 19426 68th Avenue South
> Kent, WA 98032
> Phone  253-872-7788 x313
> Fax    253-872-7904
> http://www.powertechgroup.com
> 
> 
> __________________________________________________________________
> Try AOL and get 1045 hours FREE for 45 days!
> http://free.aol.com/tryaolfree/index.adp?375380
> 
> Get AOL Instant Messenger 5.1 for FREE! Download Now!
> http://aim.aol.com/aimnew/Aim/register.adp?promos=380455
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
> 
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.