RE: Adopting authority not?

[rob@xxxxxxxxx]

John,

I really appreciate your in depth analysis.

However, we use this user ADOPT to own programs in numerous other cases.

Example
program GDIINTEDI/POEXTV is owned by ADOPT.  It is used to update this 
file:
Object . . . . . . . :   IIML01          Owner  . . . . . . . :   SSA36 
  Library  . . . . . :     CLIDIVF       Primary group  . . . :   *NONE 
Object type  . . . . :   *FILE           ASP device . . . . . :   *SYSBAS
 
Object secured by authorization list  . . . . . . . . . . . . :   *NONE 
 
                         Object 
User        Group       Authority 
SSA36                   *ALL 
*PUBLIC                 *EXCLUDE 

Remembering that SSA36  is a supplemental group of ADOPT.

I am doing some testing to see if CLRPFM is just pickier than other data 
operations.  For example, while I can create a program which adopts 
QSECOFR to create user profiles, that program cannot give that new user 
profile a group profile that the job user does not have access to. 
(Remember my QTCP ftp exit point issue?)  I am wondering if CLRPFM has 
some strange requirement.  The gent who does the most here with adopting 
was pretty sure that he does RMVM, and ADDPFM with adopted authority, but 
he didn't look like he  was willing to bet the farm on it.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 




"John Earl" <john.earl@xxxxxxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
04/03/2003 04:05 PM
Please respond to Midrange Systems Technical Discussion
 
        To:     "'Midrange Systems Technical Discussion'" 
<midrange-l@xxxxxxxxxxxx>
        cc: 
        Fax to: 
        Subject:        RE: Adopting authority not?


Rob,

 

When I read this I see.

 

*         *PUBLIC has at least *USE authority to library EDI.GDI, so there
is adequate authority to work with the existing objects in the library

*         User "SSA" owns, and has all authority to file EDI.GDI/HMDEMH01,
which is sufficient authority to " clear, initialize, or copy member".

*         *PUBLIC has *CHANGE authority to the file EDI.GDI/HMDEMH01, 
which
is insufficient authority to " clear, initialize, or copy member".

*         User "ADOPT" owns the program EDI.PGM/HMDEMC01 which attempts to
clear or copy.

*         User Profile "ADOPT" belongs to the group "SSA", but adopted
authority cannot come from the group profile of a program's owner.

*         Program EDI.PGM/HMDEMC01 runs with the authority of the calling
user plus the authority of "ADOPT", but not with the authority of 
"ADOPT"'s
group ("SSA"), therefore the operation fails.

 

>From my limited view of this, it appears that you have to either give 
ADOPT
*OBJMGT rights to the file (which seems reasonable) or have the program
adopt SSA's authority (which seems excessive).  In any case there does not
seem to be real value in having ADOPT a member of the SSA group.

 

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 

 

 

--

_______________________________________________
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.